Using OpenEmbedded

Using OpenEmbeddedUsing OpenEmbeddedAn Introduction To Building Your Own Distributions
An Introduction To Building Your Own Images
A brief overview of the
scope and issues
involved with building your own
GNU/Linux-based distributions.
Trevor Woerner
twoerner@gmail.com

April 12, 2018 RaspberryPi Meetup Toronto
twoerner@gmail.com
2 of 81
●
this talk is not specific to RaspberryPis
●
this time-slot is not long enough to cover every most
aspect/feature/workflow of OpenEmbedded
●
i don't claim to know everything about OpenEmbedded
(or much about anything else, for that matter)

twoerner@gmail.com
3 of 81
Why?

twoerner@gmail.com
4 of 81
why create your own distribution?
●
very difficult to answer for (casual) user
●
easier to answer when building products
●
tight control over installed software
●
tight control over versions of installed software
●
security
●
software updates
●
device lifetime

twoerner@gmail.com
5 of 81
Code Choices

twoerner@gmail.com
6 of 81
booting GNU/Linux
a
press power
button
bootloader kernel boot init system
display
manager /
login screen
window
manager
gui
display server
protocol
desktop
environment
text
START

twoerner@gmail.com
7 of 81
in a GNU/Linux system,
only this is "Linux"
kernel boot

twoerner@gmail.com
8 of 81
booting GNU/Linux - drilling down
bootloader
●
grub
●
u-boot
●
lilo
●
syslinux
●
systemd-boot/gummiboot
●
barebox

twoerner@gmail.com
9 of 81
kernel boot
●
latest kernel.org
●
LTS
●
evil vendor kernel
●
benevolent distro kernel
●
with or without PREEMPT_RT
●
2.6 / 3.x / 4.x
●
xenomai

twoerner@gmail.com
10 of 81
a
init system
●
sysvinit
●
systemd
●
upstart
●
busybox init
●
OpenRC
●
runit

twoerner@gmail.com
11 of 81
display server
protocol
●
X11
●
wayland
●
directfb
●
mir

twoerner@gmail.com
12 of 81
display
manager /
login screen
●
XDM
●
GDM
●
KDM
●
LXDM
●
CDM
●
xlogin
●
nodm
●
LightDM

twoerner@gmail.com
13 of 81
desktop
environment
●
GNOME
●
KDE
●
LXDE
●
MATE
●
LXQt
●
Enlightenment
●
Cinnamon
●
Unity
●
Xfce

twoerner@gmail.com
14 of 81
window
manager
●
Xfwm
●
Openbox
●
KWin
●
i3
●
FVWM
●
TWM
●
compiz
●
Matchbox
●
Metacity
●
Sawfish
●
mwm
●
uwm
●
xmonad
●
ion
●
fluxbox

twoerner@gmail.com
15 of 81
NOT booting GNU/Linux - drilling down
●
bash
●
csh
●
tcsh
●
zsh
●
sh
●
ash
●
ksh
●
mosh
●
dsh
Shells
●
gnome-terminal
●
xterm
●
konsole
●
rxvt
●
xfce4-terminal
Terminal
Emulators

twoerner@gmail.com
16 of 81
●
bash
●
csh
●
tcsh
●
zsh
●
sh
●
ash
●
ksh
●
mosh
●
dsh
Shells
●
gnome-terminal
●
xterm
●
konsole
●
rxvt
●
xfce4-terminal
Terminal
Emulators
●
apache2
●
tomcat
●
jetty
●
lighttpd
●
Nginx
●
cherokee
●
fcgi
●
hiawatha
●
monkey
●
nostromo
Web
Servers
●
chromium
●
firefox
●
links
●
epiphany
●
opic
●
midori
●
konqueror
●
qtwebbrowser
●
rekonq
Web
Browsers

twoerner@gmail.com
17 of 81
●
bash
●
csh
●
tcsh
●
zsh
●
sh
●
ash
●
ksh
●
mosh
●
dsh
Shells
●
gnome-terminal
●
xterm
●
konsole
●
rxvt
●
xfce4-terminal
Terminal
Emulators
●
apache2
●
tomcat
●
jetty
●
lighttpd
●
Nginx
●
cherokee
●
fcgi
●
hiawatha
●
monkey
●
nostromo
Web
Servers
●
OpenSSH
●
dropbear
SSH
Servers●
coreutils
●
busybox
●
toybox
Basic
Cmdline
Utilities
●
chromium
●
firefox
●
links
●
epiphany
●
opic
●
midori
●
konqueror
●
qtwebbrowser
●
rekonq
Web
Browsers
●
glibc
●
uclibc
●
musl
C
Libraries
●
coreutils
●
busybox
●
toybox
Basic
Cmdline
Utilities ●
gcc
●
llvm
C
Compilers

twoerner@gmail.com
18 of 81
●
bash
●
csh
●
tcsh
●
zsh
●
sh
●
ash
●
ksh
●
mosh
●
dsh
Shells
●
gnome-terminal
●
xterm
●
konsole
●
rxvt
●
xfce4-terminal
Terminal
Emulators
●
apache2
●
tomcat
●
jetty
●
lighttpd
●
Nginx
●
cherokee
●
fcgi
●
hiawatha
●
monkey
●
nostromo
Web
Servers
●
OpenSSH
●
dropbear
SSH
Servers●
coreutils
●
busybox
●
toybox
Basic
Cmdline
Utilities
●
db
●
gdbm
●
sqlite
●
hiera
●
metakit
●
mysql
●
postgresql
Databases
●
chromium
●
firefox
●
links
●
epiphany
●
opic
●
midori
●
konqueror
●
qtwebbrowser
●
rekonq
Web
Browsers
●
glibc
●
uclibc
●
musl
C
Libraries
●
coreutils
●
busybox
●
toybox
Basic
Cmdline
Utilities
●
java
●
python
●
go
●
rust
●
nodejs
●
ruby
●
perl
●
mono
●
smalltalk
●
erlang
●
ada
Language
Support
●
gcc
●
llvm
C
Compilers

twoerner@gmail.com
19 of 81
●
bash
●
csh
●
tcsh
●
zsh
●
sh
●
ash
●
ksh
●
mosh
●
dsh
Shells
●
gnome-terminal
●
xterm
●
konsole
●
rxvt
●
xfce4-terminal
Terminal
Emulators
●
apache2
●
tomcat
●
jetty
●
lighttpd
●
Nginx
●
cherokee
●
fcgi
●
hiawatha
●
monkey
●
nostromo
Web
Servers
●
OpenSSH
●
dropbear
SSH
Servers●
coreutils
●
busybox
●
toybox
Basic
Cmdline
Utilities
●
db
●
gdbm
●
sqlite
●
hiera
●
metakit
●
mysql
●
postgresql
Databases
●
chromium
●
firefox
●
links
●
epiphany
●
opic
●
midori
●
konqueror
●
qtwebbrowser
●
rekonq
Web
Browsers
●
glibc
●
uclibc
●
musl
C
Libraries
●
coreutils
●
busybox
●
toybox
Basic
Cmdline
Utilities
●
java
●
python
●
go
●
rust
●
nodejs
●
ruby
●
perl
●
mono
●
smalltalk
●
erlang
●
ada
Language
Support
●
gcc
●
llvm
C
Compilers
●
wolfssl
●
tpm/tpm2
●
swupd/swupdate
●
selinux
●
optee
●
ro-rootfs
●
pentesting/kali
Security ●
lxd/lxc
●
docker
●
openstack
●
criu
●
kubernetes
●
kvm
●
oci
●
xen
Virtualization

twoerner@gmail.com
20 of 81
●
bash
●
csh
●
tcsh
●
zsh
●
sh
●
ash
●
ksh
●
mosh
●
dsh
Shells
●
gnome-terminal
●
xterm
●
konsole
●
rxvt
●
xfce4-terminal
Terminal
Emulators
●
apache2
●
tomcat
●
jetty
●
lighttpd
●
Nginx
●
cherokee
●
fcgi
●
hiawatha
●
monkey
●
nostromo
Web
Servers
●
OpenSSH
●
dropbear
SSH
Servers●
coreutils
●
busybox
●
toybox
Basic
Cmdline
Utilities
●
db
●
gdbm
●
sqlite
●
hiera
●
metakit
●
mysql
●
postgresql
Databases
●
chromium
●
firefox
●
links
●
epiphany
●
opic
●
midori
●
konqueror
●
qtwebbrowser
●
rekonq
Web
Browsers
●
glibc
●
uclibc
●
musl
C
Libraries
●
coreutils
●
busybox
●
toybox
Basic
Cmdline
Utilities
●
java
●
python
●
go
●
rust
●
nodejs
●
ruby
●
perl
●
mono
●
smalltalk
●
erlang
●
ada
Language
Support
●
gcc
●
llvm
C
Compilers
●
wolfssl
●
tpm/tpm2
●
swupd/swupdate
●
selinux
●
optee
●
ro-rootfs
●
pentesting/kali
Security ●
lxd/lxc
●
docker
●
openstack
●
criu
●
kubernetes
●
kvm
●
oci
●
xen
Virtualization
VER
SIO
N
S

twoerner@gmail.com
21 of 81
●
bash
●
csh
●
tcsh
●
zsh
●
sh
●
ash
●
ksh
●
mosh
●
dsh
Shells
●
gnome-terminal
●
xterm
●
konsole
●
rxvt
●
xfce4-terminal
Terminal
Emulators
●
apache2
●
tomcat
●
jetty
●
lighttpd
●
Nginx
●
cherokee
●
fcgi
●
hiawatha
●
monkey
●
nostromo
Web
Servers
●
OpenSSH
●
dropbear
SSH
Servers●
coreutils
●
busybox
●
toybox
Basic
Cmdline
Utilities
●
db
●
gdbm
●
sqlite
●
hiera
●
metakit
●
mysql
●
postgresql
Databases
●
chromium
●
firefox
●
links
●
epiphany
●
opic
●
midori
●
konqueror
●
qtwebbrowser
●
rekonq
Web
Browsers
●
glibc
●
uclibc
●
musl
C
Libraries
●
coreutils
●
busybox
●
toybox
Basic
Cmdline
Utilities
●
java
●
python
●
go
●
rust
●
nodejs
●
ruby
●
perl
●
mono
●
smalltalk
●
erlang
●
ada
Language
Support
●
gcc
●
llvm
C
Compilers
●
wolfssl
●
tpm/tpm2
●
swupd/swupdate
●
selinux
●
optee
●
ro-rootfs
●
pentesting/kali
Security ●
lxd/lxc
●
docker
●
openstack
●
criu
●
kubernetes
●
kvm
●
oci
●
xen
Virtualization
VER
SIO
N
S
DEPENDENCIES

twoerner@gmail.com
22 of 81
a GNU/Linux system is not one single, monolithic blob
created by one company/organization
●
individual people/groups, working mostly
autonomously
●
rarely a top-level, rigid, overall, pre-developed spec
●
independent release schedules
●
multiple options at every step
●
choosing a cohesive set → DISTRIBUTION

twoerner@gmail.com
23 of 81
why "re-invent the wheel" and create alternates of
existing, working projects?
●
code forks due to disagreement in {techincal | legal |
community | leadership | ...} direction
●
real or perceived legal issues
●
re-design in order to
●
add more features
●
support more platforms
●
fundamentally change how something works
(algorithm)

twoerner@gmail.com
24 of 81
why "re-invent the wheel" and create alternates of
existing, working projects?
●
to promote "healthy" competition
●
unaware of existing projects
●
original project is abandoned
●
to "start fresh"
●
for the learning experience

twoerner@gmail.com
25 of 81
Running Code

twoerner@gmail.com
26 of 81
●
processors are the heart of any device
●
all processor families "speak" their own "language"
(sometimes sub-groups within a family have their own
"dialect")
●
a programmer's intentions, eventually, has to be
expressed in the processor's "language"
●
either by compiling/assembling/linking code
●
or by running the code through an interpreter
●
whether we're talking about compiled code, or
interpreted, at some point compiling needs to take
place (compiling of code, compiling of interpreter)

twoerner@gmail.com
27 of 81
how to compile code
●
fetch code
●
unpack
●
patch
●
configure
●
build/compile
●
stage
●
package

twoerner@gmail.com
28 of 81
fetch
●
not always obvious from where to get code
●
interact with a repository (svn, cvs, git, hg, perforce,
clearcase, rcs/sccs, darcs, monotone, GNU bazaar,
MS vss...) or tarball releases (e.g. ftp)
●
interact with a code hosting site (github,
sourceforge, bitbucket, gitlab, launchpad,
cloudforge...)
●
branches, tags
●
verify signature/checksum(s)

twoerner@gmail.com
29 of 81
unpack
●
compression
●
gzip, bzip2, xz, z, lzo, lzma
●
archive
●
tar, cpio, shar
●
compression + archive
●
7z, zip, arc, apk, tar.{gz|xz|bzip2|...}

twoerner@gmail.com
30 of 81
patch
●
when you do something (even slightly) different than
what the people who wrote the code are doing,
patches are often needed
●
different compiler
●
different/newer/older host
●
different C library
●
different versions of dependencies
●
sometimes upstream doesn't accept your patch
●
where to store/maintain these patches?

twoerner@gmail.com
31 of 81
configure
●
enable/disable features
●
build systems
●
make
●
makefile generators
●
autotools
●
cmake
●
pymake
●
"make" replacements
●
ant
●
maven
●
waf
●
ninja
●
gyp/gn
●
meson

twoerner@gmail.com
32 of 81
build/compile
●
cross-compiling
●
selecting, patching, configuring a cross-compiler
(and C lib) is non-trivial
●
using the cross-compilier is non-trivial (avoiding
host contamination)

twoerner@gmail.com
33 of 81
stage
●
preparing artifacts for the target
●
packing
●
signing
●
arranging
●
updating/removing
●
only install relevant parts (remove docs, man pages,
include files... unless user wants them explicitly)

twoerner@gmail.com
34 of 81
package
●
ipk
●
deb
●
rpm

twoerner@gmail.com
35 of 81
Target
Device

twoerner@gmail.com
36 of 81
each device has its own quirks
●
RPi
●
fat + ext partitions
●
config.txt in fat
●
Rockchip
●
multiple partitions, individual chunks per partition
●
all chunks need to run through vendor tool
●
AllWinner
●
special "fex" files (i.e. pre-dt) + script.bin
●
DragonBoard 410c
●
fastboot tools to load eMMC
●
C.H.I.P.
●
special "UBI" image
●
board needs to be in "FEL" mode
●
etc...

twoerner@gmail.com
37 of 81
Putting It
Together

twoerner@gmail.com
38 of 81
creating a distro
●
choosing amongst 1000's x 1000's of packages,
making sure there's one of each of the required
packages, dependencies, versions, ...
●
preparing the right cross-development tools
●
building (fetching, unpacking, patching, configuring,
cross-compiling, staging, packaging) the software
●
getting that software onto/into the target device in
the proper format

twoerner@gmail.com
39 of 81
OpenEmbedded

twoerner@gmail.com
40 of 81
●
targeting multiple devices!
OpenEmbedded

twoerner@gmail.com
41 of 81
OpenEmbedded
●
provides "recipes" for 1000's of packages ~>
2000ish in base layers alone
●
prepares the cross-development tools
●
builds (fetches, unpacks, patches, configures, cross-
compiles, stages, package) the software with a very
sophisticated scheduler with correct dependencies
●
creates an image for the target device in the proper
format
●
targets multiple platforms/devices with small
configuration changes (often a one line change)

twoerner@gmail.com
42 of 81
OpenEmbedded+
●
has an optional graphical front-end (toaster)
●
optionally integrates into Eclipse
●
can generate image-specific SDK and eSDK
●
the (e)SDK can be used on Linux, Windows, or
MacOS hosts (CROPS)
●
supports many hardware targets (including qemu)
across many architectures (x86, arm, ppc, mips,
riscv) and variants (32bit, 64bit) ~> 600ish

twoerner@gmail.com
43 of 81
MinnowBoard/Turbot
●
Intel Atom x86_64
●
Intel Graphics
●
1GB - 2GB DDR3
●
uSD, GbE, USB2/3
●
turbot dual/quad dual-eth
●
meta-intel
$99

twoerner@gmail.com
44 of 81
BeagleBoard/Bone
●
TI OMAP3xxx/Sitara AM3xxx
●
Cortex-A8, Cortex-A15
●
PowerVR
●
256MB - 512MB DDR2
●
SD/uSD, 10/100, USB2, PRU
●
BeagleBoard, BeagleBoard-xM,
BeagleBone, BeagleBone
Black, BeagleBoard x15
●
meta-ti
$55

twoerner@gmail.com
45 of 81
DragonBoard 410c
●
Qualcomm Snapdragon 410
●
Cortex-A53
●
Adreno 306 → Freedreno
●
2GB DDR3
●
uSD, 8GB eMMC, USB2, WiFi
2.4GHz a/b/g/n, bt 4.1
●
meta-qcom
$75

twoerner@gmail.com
46 of 81
C.H.I.P. (i.e. the $9 computer)
●
AllWinner R8
●
Cortex-A8
●
Mali-400
●
512MB DDR3
●
4GB eMMC, USB2, WiFi
2.4GHz a/b/g/n, bt 4.0
●
meta-chip
$9

twoerner@gmail.com
47 of 81
Creator Ci20
●
MIPS Ingenic JZ4780
●
PowerVR
●
1GB DDR3
●
8GB eMMC, SD, 10/100, USB2,
WiFi 2.4GHz b/g/n, bt 4.0
●
meta-jz-mips
$72

twoerner@gmail.com
48 of 81
Odroid C1/C2
●
Amlogic S805/S905
●
ARM Cortex-A5, Cortex-A53
●
Mali-450
●
1GB - 2GB DDR3
●
opt eMMC, uSD, GbE, USB2
●
meta-odroid
$40

twoerner@gmail.com
49 of 81
Odroid XU3/XU4
●
Samsung Exynos 5 Octa
●
ARM Cortex-A7 + A15
●
Mali-T628
●
2GB DDR3
●
opt eMMC, uSD, 10/100/GbE,
USB2/3
●
meta-odroid
$74

twoerner@gmail.com
50 of 81
Zybo-Zynq7
●
Xilinx Zynq 7Z007S
●
ARM Cortex-A9
●
512MB DDR3
●
PMOD, uSD, USB2
●
meta-xilinx
$189

twoerner@gmail.com
51 of 81
Pine64
●
AllWinner A64
●
ARM Cortex-A53
●
Mali-400
●
512MB DDR3
●
uSD, 10/100, USB2
●
meta-pine64
$189

twoerner@gmail.com
52 of 81
Firefly-RK3288
●
Rockchip RK3288
●
ARM Cortex-A17
●
Mali-T760
●
2GB - 4GB DDR3
●
16GB eMMC, uSD, GbE, WiFi
a/b/g/n/ac, bt 4.0+ble, USB2
●
meta-rockchip
$129

twoerner@gmail.com
53 of 81
Firefly-RK3399
●
Rockchip RK3399 Hexacore
●
ARM Cortex-A72 + A53
●
Mali-T860
●
2GB - 4GB DDR3
●
16GB - 32GB eMMC, uSD,
GbE, WiFi a/b/g/n/ac, bt 4.1,
USB2/3
●
meta-rockchip
$139

twoerner@gmail.com
54 of 81
Wandboard
●
Freescale iMX6
●
ARM Cortex-A9
●
Vivante → Etnaviv
●
1GB DDR3
●
uSD, GbE, WiFi n, USB2
●
solo, dual, quad
●
meta-freescale-3rdparty
$69

twoerner@gmail.com
55 of 81
Raspberry Pi
●
Broadcom BCM2835 BCM2836
BCM2837
●
ARM11, Cortex-A7, Cortex-A53
●
Broadcom VC4
●
512MB - 1GB DDR2
●
uSD, 10/100, USB2
●
Rpi A/B, Rpi2, Rpi0, Rpi3,
Rpi3B+
●
meta-raspberrypi
$35

twoerner@gmail.com
56 of 81
Banana Pi
●
AllWinner A20
●
Cortex-A7
●
Mali-400
●
1GB DDR3
●
SD, GbE, USB2
●
meta-sunxi
$32

twoerner@gmail.com
57 of 81
Orange Pi
●
AllWinner A20/H2/H3
●
Cortex-A7
●
Mali-400
●
1GB - 2GB DDR3
●
uSD, GbE, USB2
●
meta-sunxi
$25

twoerner@gmail.com
58 of 81
OpenEmbedded++
●
runs on most GNU/Linux distributions (debian,
ubuntu, fedora, centOS, openSUSE)
●
is mostly host-independent (builds it own set of
-native tools)
●
extensive test framework (build tests, package unit-
tests, on-target tests, image/boot tests)
●
license/legal audit or constraint
●
speeds up subsequent builds with sophisticated
sstate cache

twoerner@gmail.com
59 of 81
OpenEmbedded+++
●
excellent documentation, community, help (ISVs)
●
official Linux Foundation project (Yocto)
do you work for Intel
or the Linux Foundation?
whether to say
"Yocto" or "OE"
say "OE"say "Yocto"
yes no

twoerner@gmail.com
60 of 81
There are only
two hard things in
Computer Science:
0. off-by-one errors
1. cache invalidation
2. naming things
Phil Karlton

twoerner@gmail.com
61 of 81
There are only
two hard things in
Computer Science:
0. off-by-one errors
7. asynchronous callbacks
1. cache invalidation
2. naming things

twoerner@gmail.com
62 of 81
OpenEmbedded/Yocto/Poky Naming
●
a long time ago, this entire thing was called Poky
(i.e. "the Poky Build System")
●
now Poky is a reference distribution for
testing/releases
●
now the base recipes and classes are called
OpenEmbedded, but was tied too heavily to one
vendor
●
when the LF adopted OE, it was renamed Yocto in
an attempt to make it vendor-neutral

twoerner@gmail.com
63 of 81
How Does
It Work?

twoerner@gmail.com
64 of 81
recipes
●
a file with the necessary data to process a package
classes
●
a grouping of similar functionality
layers
●
a set of related recipes, classes, data for a specific
purpose (BSP, software, distro)
bitbake
●
the tool which runs the whole build
configuration files
●
e.g. conf/local.conf

twoerner@gmail.com
65 of 81
sample recipe (openembedded-core/meta/recipes-graphics/mesa/mesa -- abridged)
SUMMARY = "A free implementation of the OpenGL API"
DESCRIPTION = "Mesa is an open-source implementation of the OpenGL specification -
a system for rendering interactive 3D graphics.
A variety of device drivers allows Mesa to be used in many different environments
ranging from software emulation to complete hardware acceleration for modern GPUs.
Mesa is used as part of the overall Direct Rendering Infrastructure and X.org
environment."
HOMEPAGE = "http://mesa3d.org"
BUGTRACKER = "https://bugs.freedesktop.org"
SECTION = "X11"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://docs/license.html;md5=725f991a1cc322aa7a0cd3a2016621c4"
DEPENDS = "expat makedepend-native zlib"
PROVIDES = "virtual/libgl virtual/libgles1 virtual/libgles2 virtual/egl"
inherit autotools pkgconfig python3native gettext distro_features_check
PACKAGECONFIG ??= "x11 dri3"
PACKAGECONFIG[dri3] = "--enable-dri3,--disable-dri3,dri3proto presentproto libxshmfence"
SRC_URI = "https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz
file://disable-asm-on-non-gcc.patch"
SRC_URI[md5sum] = "203d1a79156ab6926f2d253b377e9d9d"
SRC_URI[sha256sum] = "8f9d9bf281c48e4a8f5228816577263b4c655248dc7666e75034ab422951a6b1"

twoerner@gmail.com
66 of 81
preamble
environment."
SECTION = "X11"
LICENSE = "MIT"

twoerner@gmail.com
67 of 81
license
environment."
SECTION = "X11"
LICENSE = "MIT"

twoerner@gmail.com
68 of 81
alternates of same purpose
environment."
SECTION = "X11"
LICENSE = "MIT"

twoerner@gmail.com
69 of 81
adding classes of known functionality
environment."
SECTION = "X11"
LICENSE = "MIT"

twoerner@gmail.com
70 of 81
configuration options
environment."
SECTION = "X11"
LICENSE = "MIT"

twoerner@gmail.com
71 of 81
dependencies (build and native)
environment."
SECTION = "X11"
LICENSE = "MIT"

twoerner@gmail.com
72 of 81
fetch: location, patch, signature verification
environment."
SECTION = "X11"
LICENSE = "MIT"

twoerner@gmail.com
73 of 81
layers (conf/bblayers.conf)
# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "7"
BBPATH = "${TOPDIR}"
BBFILES ?= ""
BBLAYERS ?= "
/opt/oe/configs/z/build-master/rpi3-64-vc4/layers/meta-raspberrypi
/opt/oe/configs/z/build-master/rpi3-64-vc4/layers/openembedded-core/meta
/opt/oe/configs/z/build-master/rpi3-64-vc4/layers/meta-openembedded/meta-oe
/opt/oe/configs/z/build-master/rpi3-64-vc4/layers/meta-openembedded/meta-gnome
/opt/oe/configs/z/build-master/rpi3-64-vc4/layers/meta-openembedded/meta-python
/opt/oe/configs/z/build-master/rpi3-64-vc4/layers/meta-openembedded/meta-networking
/opt/oe/configs/z/build-master/rpi3-64-vc4/layers/meta-openembedded/meta-multimedia
/opt/oe/configs/z/build-master/rpi3-64-vc4/layers/meta-qt5
/opt/oe/configs/z/build-master/rpi3-64-vc4/layers/meta-qt5-extra
/opt/oe/configs/z/build-master/rpi3-64-vc4/layers/meta-browser
"

twoerner@gmail.com
74 of 81
configuration (conf/local.conf -- abridged)
MACHINE ?= "raspberrypi3-64"
DISTRO ?= "nodistro"
DL_DIR ?= "/opt/Downloads"
# gui/gl
MACHINE_FEATURES_append = " vc4graphics"
DISTRO_FEATURES_append = " directfb opengl x11"
PACKAGECONFIG_append_pn-mesa-demos = " glut"
CORE_IMAGE_EXTRA_INSTALL += " glmark2 mesa-demos chromium-x11"
# touchscreen
PACKAGECONFIG_pn-xserver-nodm-init = "nocursor"
WAVESHARE_1024X600_C_2_1 = "1"
# rpi
ENABLE_I2C = "1"
KERNEL_MODULE_AUTOLOAD += "i2c-dev"
ENABLE_SPI_BUS = "1"
ENABLE_UART = "1"
PACKAGE_CLASSES = "package_ipk"
EXTRA_IMAGE_FEATURES ?= "debug-tweaks"

twoerner@gmail.com
75 of 81
Case Study

twoerner@gmail.com
76 of 81
customers
hardware
manufacturers
Comcast

twoerner@gmail.com
77 of 81
Comcast set-top-box
●
purposefully multi-vendor, multi-architecture
●
but expects a base, functioning system
●
needs to add its own software on top
●
needs to tightly control the base system
●
packages
●
versions
●
functionality (e.g. init system, graphics)

twoerner@gmail.com
78 of 81
OpenEmbedded solution
●
Comcast creates its own distro → RDK (layer)
●
defines packages, behaviour
●
vendors create hardware and provide BSP layers
●
Comcast builds images for each device using distro
layer, BSP layer, as well as others
●
Comcast generates SDKs for their developers
●
Comcast maintains a packagefeed for updates
●
this is not a "home grown" solution, embedded
developers are already familiar with the tools

twoerner@gmail.com
79 of 81
Caveats

twoerner@gmail.com
80 of 81
●
not all layers work well together
●
OpenEmbedded doesn't catch all mistakes and mis-
matches
●
code is constantly changing, and getting all these
independent projects to work as a cohesive whole
isn't always easy (moving target)
●
layer quality, layer duplications
●
needs a really big build machine
●
works better with a really good connection to the
Internet
●
... and more

twoerner@gmail.com
81 of 81
Thank you!

Using OpenEmbedded

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Using OpenEmbedded

Semelhante a Using OpenEmbedded (20)

Mais de Trevor Woerner

Mais de Trevor Woerner (6)

Último

Último (20)

Using OpenEmbedded