summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorAdrian Dudau <adrian.dudau@enea.com>2017-08-30 15:45:02 +0200
committerAdrian Dudau <adrian.dudau@enea.com>2017-09-01 10:51:20 +0200
commit9528b94a291d648bb62f28826e2b946a229c8cb0 (patch)
treebadcab9e0ff1d1cad2ae1a74697ce1114bd610b8
downloadmeta-el-nfv-access-9528b94a291d648bb62f28826e2b946a229c8cb0.tar.gz
Initial commit
Signed-off-by: Adrian Dudau <adrian.dudau@enea.com>
-rw-r--r--COPYING.MIT17
-rw-r--r--README71
-rw-r--r--conf/layer.conf14
-rw-r--r--conf/template.inteld1521-sdk/bblayers.conf.sample24
-rw-r--r--conf/template.inteld1521-sdk/conf-notes.txt2
-rw-r--r--conf/template.inteld1521-sdk/local.conf.sample239
-rw-r--r--conf/template.inteld1521/bblayers.conf.sample24
-rw-r--r--conf/template.inteld1521/conf-notes.txt4
-rw-r--r--conf/template.inteld1521/local.conf.sample237
-rw-r--r--conf/template.qemux86-64/bblayers.conf.sample22
-rw-r--r--conf/template.qemux86-64/conf-notes.txt3
-rw-r--r--conf/template.qemux86-64/local.conf.sample237
-rw-r--r--images/build-qcow-image.inc10
-rw-r--r--images/enea-image-nfv-access-common.inc13
-rw-r--r--images/enea-image-nfv-access-guest-sdk.bb13
-rw-r--r--images/enea-image-nfv-access-guest.bb9
-rw-r--r--images/enea-image-nfv-access-host-common.inc12
-rw-r--r--images/enea-image-nfv-access-host-odm.bb3
-rw-r--r--images/enea-image-nfv-access-host-openstack.bb17
-rw-r--r--images/enea-image-nfv-access-host-sdk.bb18
-rw-r--r--images/enea-image-nfv-access-host.bb3
21 files changed, 992 insertions, 0 deletions
diff --git a/COPYING.MIT b/COPYING.MIT
new file mode 100644
index 0000000..89de354
--- /dev/null
+++ b/COPYING.MIT
@@ -0,0 +1,17 @@
1Permission is hereby granted, free of charge, to any person obtaining a copy
2of this software and associated documentation files (the "Software"), to deal
3in the Software without restriction, including without limitation the rights
4to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
5copies of the Software, and to permit persons to whom the Software is
6furnished to do so, subject to the following conditions:
7
8The above copyright notice and this permission notice shall be included in
9all copies or substantial portions of the Software.
10
11THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
12IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
13FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
14AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
15LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
16OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
17THE SOFTWARE.
diff --git a/README b/README
new file mode 100644
index 0000000..de54856
--- /dev/null
+++ b/README
@@ -0,0 +1,71 @@
1meta-el-nfv-access
2===================================================================
3
4This layer contains distro customizations specific to the Enea Linux
5NFV Access platform releases.
6
7Dependencies
8============
9
10This layer depends on:
11
12 URI: git://git.yoctoproject.org/poky
13 branch: pyro
14
15 URI: git://git.enea.com/linux/meta-el-common
16 branch: pyro
17
18 URI: git://git.enea.com/linux/meta-enea-virtualization
19 branch: pyro
20
21 URI: git://git.enea.com/linux/meta-cloud-services/meta-openstack
22 branch: pyro
23
24
25
26Source code
27===========
28
29git://git.enea.com/linux/meta-el-nfv-access.git
30
31
32Patches
33=======
34
35Please submit any patches against the el-nfv-access layer to the
36following mailing list: linux@lists.enea.com
37
38Maintainers:
39Adrian Dudau <adrian.dudau@enea.com>
40Martin Borg <martin.borg@enea.com>
41
42Table
43=================
44
45 I. Adding the el-nfv-access layer to your build
46 II. Misc
47
48
49I. Adding the el-nfv-access layer to your build
50=================================================
51
52In order to use this layer, you need to make the build system aware of
53it.
54
55Assuming the el-nfv-access layer exists at the top-level of your
56yocto build tree, you can add it to the build system by adding the
57location of the el-nfv-access layer to bblayers.conf, along with any
58other layers needed. e.g.:
59
60
61 BBLAYERS ?= " \
62 /path/to/yocto/meta \
63 /path/to/yocto/meta-poky \
64 /path/to/yocto/meta-el-common \
65 /path/to/yocto/meta-enea-virtualization \
66 /path/to/yocto/meta-cloud-services/meta-openstack \
67 /path/to/yocto/meta-el-nfv-access \
68 "
69
70II. Misc
71========
diff --git a/conf/layer.conf b/conf/layer.conf
new file mode 100644
index 0000000..04b8042
--- /dev/null
+++ b/conf/layer.conf
@@ -0,0 +1,14 @@
1# We have a conf and classes directory, add to BBPATH
2BBPATH .= ":${LAYERDIR}"
3
4# We have recipes-* directories, add to BBFILES
5BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
6 ${LAYERDIR}/images/* \
7 ${LAYERDIR}/packagegroups/* \
8 ${LAYERDIR}/recipes-*/*/*.bbappend"
9
10BBFILE_COLLECTIONS += "el-nfv-access"
11BBFILE_PATTERN_el-nfv-access = "^${LAYERDIR}/"
12BBFILE_PRIORITY_el-nfv-access = "7"
13LAYERDEPENDS_el-nfv-access = "el-common enea-virtualization openstack-layer"
14BBMASK += "/meta-cloud-services/meta-openstack/recipes-kernel/linux/"
diff --git a/conf/template.inteld1521-sdk/bblayers.conf.sample b/conf/template.inteld1521-sdk/bblayers.conf.sample
new file mode 100644
index 0000000..886166e
--- /dev/null
+++ b/conf/template.inteld1521-sdk/bblayers.conf.sample
@@ -0,0 +1,24 @@
1# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
2# changes incompatibly
3POKY_BBLAYERS_CONF_VERSION = "2"
4
5BBPATH = "${TOPDIR}"
6BBFILES ?= ""
7
8BBLAYERS ?= " \
9 ##OEROOT##/meta \
10 ##OEROOT##/meta-el-common \
11 ##OEROOT##/meta-el-nfv-access \
12 ##OEROOT##/meta-enea-virtualization \
13 ##OEROOT##/meta-enea-bsp-x86 \
14 ##OEROOT##/meta-intel \
15 ##OEROOT##/meta-openembedded/meta-oe \
16 ##OEROOT##/meta-openembedded/meta-networking \
17 ##OEROOT##/meta-openembedded/meta-filesystems \
18 ##OEROOT##/meta-openembedded/meta-python \
19 ##OEROOT##/meta-openembedded/meta-webserver \
20 ##OEROOT##/meta-virtualization \
21 ##OEROOT##/meta-poky \
22 ##OEROOT##/meta-cloud-services \
23 ##OEROOT##/meta-cloud-services/meta-openstack \
24 "
diff --git a/conf/template.inteld1521-sdk/conf-notes.txt b/conf/template.inteld1521-sdk/conf-notes.txt
new file mode 100644
index 0000000..3dd7ea1
--- /dev/null
+++ b/conf/template.inteld1521-sdk/conf-notes.txt
@@ -0,0 +1,2 @@
1Common targets are:
2 enea-image-nfv-access-host-sdk
diff --git a/conf/template.inteld1521-sdk/local.conf.sample b/conf/template.inteld1521-sdk/local.conf.sample
new file mode 100644
index 0000000..a156f32
--- /dev/null
+++ b/conf/template.inteld1521-sdk/local.conf.sample
@@ -0,0 +1,239 @@
1#
2# This file is your local configuration file and is where all local user settings
3# are placed. The comments in this file give some guide to the options a new user
4# to the system might want to change but pretty much any configuration option can
5# be set in this file. More adventurous users can look at local.conf.extended
6# which contains other examples of configuration which can be placed in this file
7# but new users likely won't need any of them initially.
8#
9# Lines starting with the '#' character are commented out and in some cases the
10# default values are provided as comments to show people example syntax. Enabling
11# the option is a question of removing the # character and making any change to the
12# variable as required.
13
14#
15# Machine Selection
16#
17# You need to select a specific machine to target the build with. There are a selection
18# of emulated machines available which can boot and run in the QEMU emulator:
19#
20#MACHINE ?= "qemuarm"
21#MACHINE ?= "qemuarm64"
22#MACHINE ?= "qemumips"
23#MACHINE ?= "qemumips64"
24#MACHINE ?= "qemuppc"
25#MACHINE ?= "qemux86"
26#MACHINE ?= "qemux86-64"
27#
28# There are also the following hardware board target machines included for
29# demonstration purposes:
30#
31#MACHINE ?= "beaglebone"
32#MACHINE ?= "genericx86"
33#MACHINE ?= "genericx86-64"
34#MACHINE ?= "mpc8315e-rdb"
35#MACHINE ?= "edgerouter"
36#
37# This sets the default machine to be qemux86 if no other machine is selected:
38MACHINE ?= "inteld1521"
39
40#
41# Where to place downloads
42#
43# During a first build the system will download many different source code tarballs
44# from various upstream projects. This can take a while, particularly if your network
45# connection is slow. These are all stored in DL_DIR. When wiping and rebuilding you
46# can preserve this directory to speed up this part of subsequent builds. This directory
47# is safe to share between multiple builds on the same machine too.
48#
49# The default is a downloads directory under TOPDIR which is the build directory.
50#
51#DL_DIR ?= "${TOPDIR}/downloads"
52
53#
54# Where to place shared-state files
55#
56# BitBake has the capability to accelerate builds based on previously built output.
57# This is done using "shared state" files which can be thought of as cache objects
58# and this option determines where those files are placed.
59#
60# You can wipe out TMPDIR leaving this directory intact and the build would regenerate
61# from these files if no changes were made to the configuration. If changes were made
62# to the configuration, only shared state files where the state was still valid would
63# be used (done using checksums).
64#
65# The default is a sstate-cache directory under TOPDIR.
66#
67#SSTATE_DIR ?= "${TOPDIR}/sstate-cache"
68
69#
70# Where to place the build output
71#
72# This option specifies where the bulk of the building work should be done and
73# where BitBake should place its temporary files and output. Keep in mind that
74# this includes the extraction and compilation of many applications and the toolchain
75# which can use Gigabytes of hard disk space.
76#
77# The default is a tmp directory under TOPDIR.
78#
79#TMPDIR = "${TOPDIR}/tmp"
80
81#
82# Default policy config
83#
84# The distribution setting controls which policy settings are used as defaults.
85# The default value is fine for general Yocto project use, at least initially.
86# Ultimately when creating custom policy, people will likely end up subclassing
87# these defaults.
88#
89DISTRO ?= "enea"
90# As an example of a subclass there is a "bleeding" edge policy configuration
91# where many versions are set to the absolute latest code from the upstream
92# source control systems. This is just mentioned here as an example, its not
93# useful to most new users.
94# DISTRO ?= "poky-bleeding"
95
96#
97# Package Management configuration
98#
99# This variable lists which packaging formats to enable. Multiple package backends
100# can be enabled at once and the first item listed in the variable will be used
101# to generate the root filesystems.
102# Options are:
103# - 'package_deb' for debian style deb files
104# - 'package_ipk' for ipk files are used by opkg (a debian style embedded package manager)
105# - 'package_rpm' for rpm style packages
106# E.g.: PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk"
107# We default to rpm:
108PACKAGE_CLASSES ?= "package_deb"
109
110#
111# SDK/ADT target architecture
112#
113# This variable specifies the architecture to build SDK/ADT items for and means
114# you can build the SDK packages for architectures other than the machine you are
115# running the build on (i.e. building i686 packages on an x86_64 host).
116# Supported values are i686 and x86_64
117#SDKMACHINE ?= "i686"
118
119#
120# Extra image configuration defaults
121#
122# The EXTRA_IMAGE_FEATURES variable allows extra packages to be added to the generated
123# images. Some of these options are added to certain image types automatically. The
124# variable can contain the following options:
125# "dbg-pkgs" - add -dbg packages for all installed packages
126# (adds symbol information for debugging/profiling)
127# "dev-pkgs" - add -dev packages for all installed packages
128# (useful if you want to develop against libs in the image)
129# "ptest-pkgs" - add -ptest packages for all ptest-enabled packages
130# (useful if you want to run the package test suites)
131# "tools-sdk" - add development tools (gcc, make, pkgconfig etc.)
132# "tools-debug" - add debugging tools (gdb, strace)
133# "eclipse-debug" - add Eclipse remote debugging support
134# "tools-profile" - add profiling tools (oprofile, lttng, valgrind)
135# "tools-testapps" - add useful testing tools (ts_print, aplay, arecord etc.)
136# "debug-tweaks" - make an image suitable for development
137# e.g. ssh root access has a blank password
138# There are other application targets that can be used here too, see
139# meta/classes/image.bbclass and meta/classes/core-image.bbclass for more details.
140# We default to enabling the debugging tweaks.
141EXTRA_IMAGE_FEATURES = "debug-tweaks"
142
143#
144# Additional image features
145#
146# The following is a list of additional classes to use when building images which
147# enable extra features. Some available options which can be included in this variable
148# are:
149# - 'buildstats' collect build statistics
150# - 'image-mklibs' to reduce shared library files size for an image
151# - 'image-prelink' in order to prelink the filesystem image
152# - 'image-swab' to perform host system intrusion detection
153# NOTE: if listing mklibs & prelink both, then make sure mklibs is before prelink
154# NOTE: mklibs also needs to be explicitly enabled for a given image, see local.conf.extended
155USER_CLASSES ?= "buildstats image-mklibs image-prelink"
156
157#
158# Runtime testing of images
159#
160# The build system can test booting virtual machine images under qemu (an emulator)
161# after any root filesystems are created and run tests against those images. To
162# enable this uncomment this line. See classes/testimage(-auto).bbclass for
163# further details.
164#TEST_IMAGE = "1"
165#
166# Interactive shell configuration
167#
168# Under certain circumstances the system may need input from you and to do this it
169# can launch an interactive shell. It needs to do this since the build is
170# multithreaded and needs to be able to handle the case where more than one parallel
171# process may require the user's attention. The default is iterate over the available
172# terminal types to find one that works.
173#
174# Examples of the occasions this may happen are when resolving patches which cannot
175# be applied, to use the devshell or the kernel menuconfig
176#
177# Supported values are auto, gnome, xfce, rxvt, screen, konsole (KDE 3.x only), none
178# Note: currently, Konsole support only works for KDE 3.x due to the way
179# newer Konsole versions behave
180#OE_TERMINAL = "auto"
181# By default disable interactive patch resolution (tasks will just fail instead):
182PATCHRESOLVE = "noop"
183
184#
185# Disk Space Monitoring during the build
186#
187# Monitor the disk space during the build. If there is less that 1GB of space or less
188# than 100K inodes in any key build location (TMPDIR, DL_DIR, SSTATE_DIR), gracefully
189# shutdown the build. If there is less that 100MB or 1K inodes, perform a hard abort
190# of the build. The reason for this is that running completely out of space can corrupt
191# files and damages the build in ways which may not be easily recoverable.
192# It's necesary to monitor /tmp, if there is no space left the build will fail
193# with very exotic errors.
194BB_DISKMON_DIRS = "\
195 STOPTASKS,${TMPDIR},1G,100K \
196 STOPTASKS,${DL_DIR},1G,100K \
197 STOPTASKS,${SSTATE_DIR},1G,100K \
198 STOPTASKS,/tmp,100M,100K \
199 ABORT,${TMPDIR},100M,1K \
200 ABORT,${DL_DIR},100M,1K \
201 ABORT,${SSTATE_DIR},100M,1K \
202 ABORT,/tmp,10M,1K"
203
204#
205# Shared-state files from other locations
206#
207# As mentioned above, shared state files are prebuilt cache data objects which can
208# used to accelerate build time. This variable can be used to configure the system
209# to search other mirror locations for these objects before it builds the data itself.
210#
211# This can be a filesystem directory, or a remote url such as http or ftp. These
212# would contain the sstate-cache results from previous builds (possibly from other
213# machines). This variable works like fetcher MIRRORS/PREMIRRORS and points to the
214# cache locations to check for the shared objects.
215# NOTE: if the mirror uses the same structure as SSTATE_DIR, you need to add PATH
216# at the end as shown in the examples below. This will be substituted with the
217# correct path within the directory structure.
218#SSTATE_MIRRORS ?= "\
219#file://.* http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \n \
220#file://.* file:///some/local/dir/sstate/PATH"
221
222
223#
224# Qemu configuration
225#
226# By default qemu will build with a builtin VNC server where graphical output can be
227# seen. The two lines below enable the SDL backend too. By default libsdl-native will
228# be built, if you want to use your host's libSDL instead of the minimal libsdl built
229# by libsdl-native then uncomment the ASSUME_PROVIDED line below.
230PACKAGECONFIG_append_pn-qemu-native = " sdl"
231PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
232#ASSUME_PROVIDED += "libsdl-native"
233
234# CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to
235# track the version of this file when it was generated. This can safely be ignored if
236# this doesn't mean anything to you.
237CONF_VERSION = "1"
238
239PREFERRED_PROVIDER_virtual/kernel = "linux-intel-sdk"
diff --git a/conf/template.inteld1521/bblayers.conf.sample b/conf/template.inteld1521/bblayers.conf.sample
new file mode 100644
index 0000000..886166e
--- /dev/null
+++ b/conf/template.inteld1521/bblayers.conf.sample
@@ -0,0 +1,24 @@
1# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
2# changes incompatibly
3POKY_BBLAYERS_CONF_VERSION = "2"
4
5BBPATH = "${TOPDIR}"
6BBFILES ?= ""
7
8BBLAYERS ?= " \
9 ##OEROOT##/meta \
10 ##OEROOT##/meta-el-common \
11 ##OEROOT##/meta-el-nfv-access \
12 ##OEROOT##/meta-enea-virtualization \
13 ##OEROOT##/meta-enea-bsp-x86 \
14 ##OEROOT##/meta-intel \
15 ##OEROOT##/meta-openembedded/meta-oe \
16 ##OEROOT##/meta-openembedded/meta-networking \
17 ##OEROOT##/meta-openembedded/meta-filesystems \
18 ##OEROOT##/meta-openembedded/meta-python \
19 ##OEROOT##/meta-openembedded/meta-webserver \
20 ##OEROOT##/meta-virtualization \
21 ##OEROOT##/meta-poky \
22 ##OEROOT##/meta-cloud-services \
23 ##OEROOT##/meta-cloud-services/meta-openstack \
24 "
diff --git a/conf/template.inteld1521/conf-notes.txt b/conf/template.inteld1521/conf-notes.txt
new file mode 100644
index 0000000..53ebbe6
--- /dev/null
+++ b/conf/template.inteld1521/conf-notes.txt
@@ -0,0 +1,4 @@
1Common targets are:
2 enea-image-nfv-access-host
3 enea-image-nfv-access-host-odm
4 enea-image-nfv-access-host-openstack
diff --git a/conf/template.inteld1521/local.conf.sample b/conf/template.inteld1521/local.conf.sample
new file mode 100644
index 0000000..1a7e915
--- /dev/null
+++ b/conf/template.inteld1521/local.conf.sample
@@ -0,0 +1,237 @@
1#
2# This file is your local configuration file and is where all local user settings
3# are placed. The comments in this file give some guide to the options a new user
4# to the system might want to change but pretty much any configuration option can
5# be set in this file. More adventurous users can look at local.conf.extended
6# which contains other examples of configuration which can be placed in this file
7# but new users likely won't need any of them initially.
8#
9# Lines starting with the '#' character are commented out and in some cases the
10# default values are provided as comments to show people example syntax. Enabling
11# the option is a question of removing the # character and making any change to the
12# variable as required.
13
14#
15# Machine Selection
16#
17# You need to select a specific machine to target the build with. There are a selection
18# of emulated machines available which can boot and run in the QEMU emulator:
19#
20#MACHINE ?= "qemuarm"
21#MACHINE ?= "qemuarm64"
22#MACHINE ?= "qemumips"
23#MACHINE ?= "qemumips64"
24#MACHINE ?= "qemuppc"
25#MACHINE ?= "qemux86"
26#MACHINE ?= "qemux86-64"
27#
28# There are also the following hardware board target machines included for
29# demonstration purposes:
30#
31#MACHINE ?= "beaglebone"
32#MACHINE ?= "genericx86"
33#MACHINE ?= "genericx86-64"
34#MACHINE ?= "mpc8315e-rdb"
35#MACHINE ?= "edgerouter"
36#
37# This sets the default machine to be qemux86 if no other machine is selected:
38MACHINE ?= "inteld1521"
39
40#
41# Where to place downloads
42#
43# During a first build the system will download many different source code tarballs
44# from various upstream projects. This can take a while, particularly if your network
45# connection is slow. These are all stored in DL_DIR. When wiping and rebuilding you
46# can preserve this directory to speed up this part of subsequent builds. This directory
47# is safe to share between multiple builds on the same machine too.
48#
49# The default is a downloads directory under TOPDIR which is the build directory.
50#
51#DL_DIR ?= "${TOPDIR}/downloads"
52
53#
54# Where to place shared-state files
55#
56# BitBake has the capability to accelerate builds based on previously built output.
57# This is done using "shared state" files which can be thought of as cache objects
58# and this option determines where those files are placed.
59#
60# You can wipe out TMPDIR leaving this directory intact and the build would regenerate
61# from these files if no changes were made to the configuration. If changes were made
62# to the configuration, only shared state files where the state was still valid would
63# be used (done using checksums).
64#
65# The default is a sstate-cache directory under TOPDIR.
66#
67#SSTATE_DIR ?= "${TOPDIR}/sstate-cache"
68
69#
70# Where to place the build output
71#
72# This option specifies where the bulk of the building work should be done and
73# where BitBake should place its temporary files and output. Keep in mind that
74# this includes the extraction and compilation of many applications and the toolchain
75# which can use Gigabytes of hard disk space.
76#
77# The default is a tmp directory under TOPDIR.
78#
79#TMPDIR = "${TOPDIR}/tmp"
80
81#
82# Default policy config
83#
84# The distribution setting controls which policy settings are used as defaults.
85# The default value is fine for general Yocto project use, at least initially.
86# Ultimately when creating custom policy, people will likely end up subclassing
87# these defaults.
88#
89DISTRO ?= "enea"
90# As an example of a subclass there is a "bleeding" edge policy configuration
91# where many versions are set to the absolute latest code from the upstream
92# source control systems. This is just mentioned here as an example, its not
93# useful to most new users.
94# DISTRO ?= "poky-bleeding"
95
96#
97# Package Management configuration
98#
99# This variable lists which packaging formats to enable. Multiple package backends
100# can be enabled at once and the first item listed in the variable will be used
101# to generate the root filesystems.
102# Options are:
103# - 'package_deb' for debian style deb files
104# - 'package_ipk' for ipk files are used by opkg (a debian style embedded package manager)
105# - 'package_rpm' for rpm style packages
106# E.g.: PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk"
107# We default to rpm:
108PACKAGE_CLASSES ?= "package_deb"
109
110#
111# SDK/ADT target architecture
112#
113# This variable specifies the architecture to build SDK/ADT items for and means
114# you can build the SDK packages for architectures other than the machine you are
115# running the build on (i.e. building i686 packages on an x86_64 host).
116# Supported values are i686 and x86_64
117#SDKMACHINE ?= "i686"
118
119#
120# Extra image configuration defaults
121#
122# The EXTRA_IMAGE_FEATURES variable allows extra packages to be added to the generated
123# images. Some of these options are added to certain image types automatically. The
124# variable can contain the following options:
125# "dbg-pkgs" - add -dbg packages for all installed packages
126# (adds symbol information for debugging/profiling)
127# "dev-pkgs" - add -dev packages for all installed packages
128# (useful if you want to develop against libs in the image)
129# "ptest-pkgs" - add -ptest packages for all ptest-enabled packages
130# (useful if you want to run the package test suites)
131# "tools-sdk" - add development tools (gcc, make, pkgconfig etc.)
132# "tools-debug" - add debugging tools (gdb, strace)
133# "eclipse-debug" - add Eclipse remote debugging support
134# "tools-profile" - add profiling tools (oprofile, lttng, valgrind)
135# "tools-testapps" - add useful testing tools (ts_print, aplay, arecord etc.)
136# "debug-tweaks" - make an image suitable for development
137# e.g. ssh root access has a blank password
138# There are other application targets that can be used here too, see
139# meta/classes/image.bbclass and meta/classes/core-image.bbclass for more details.
140# We default to enabling the debugging tweaks.
141EXTRA_IMAGE_FEATURES = "debug-tweaks"
142
143#
144# Additional image features
145#
146# The following is a list of additional classes to use when building images which
147# enable extra features. Some available options which can be included in this variable
148# are:
149# - 'buildstats' collect build statistics
150# - 'image-mklibs' to reduce shared library files size for an image
151# - 'image-prelink' in order to prelink the filesystem image
152# - 'image-swab' to perform host system intrusion detection
153# NOTE: if listing mklibs & prelink both, then make sure mklibs is before prelink
154# NOTE: mklibs also needs to be explicitly enabled for a given image, see local.conf.extended
155USER_CLASSES ?= "buildstats image-mklibs image-prelink"
156
157#
158# Runtime testing of images
159#
160# The build system can test booting virtual machine images under qemu (an emulator)
161# after any root filesystems are created and run tests against those images. To
162# enable this uncomment this line. See classes/testimage(-auto).bbclass for
163# further details.
164#TEST_IMAGE = "1"
165#
166# Interactive shell configuration
167#
168# Under certain circumstances the system may need input from you and to do this it
169# can launch an interactive shell. It needs to do this since the build is
170# multithreaded and needs to be able to handle the case where more than one parallel
171# process may require the user's attention. The default is iterate over the available
172# terminal types to find one that works.
173#
174# Examples of the occasions this may happen are when resolving patches which cannot
175# be applied, to use the devshell or the kernel menuconfig
176#
177# Supported values are auto, gnome, xfce, rxvt, screen, konsole (KDE 3.x only), none
178# Note: currently, Konsole support only works for KDE 3.x due to the way
179# newer Konsole versions behave
180#OE_TERMINAL = "auto"
181# By default disable interactive patch resolution (tasks will just fail instead):
182PATCHRESOLVE = "noop"
183
184#
185# Disk Space Monitoring during the build
186#
187# Monitor the disk space during the build. If there is less that 1GB of space or less
188# than 100K inodes in any key build location (TMPDIR, DL_DIR, SSTATE_DIR), gracefully
189# shutdown the build. If there is less that 100MB or 1K inodes, perform a hard abort
190# of the build. The reason for this is that running completely out of space can corrupt
191# files and damages the build in ways which may not be easily recoverable.
192# It's necesary to monitor /tmp, if there is no space left the build will fail
193# with very exotic errors.
194BB_DISKMON_DIRS = "\
195 STOPTASKS,${TMPDIR},1G,100K \
196 STOPTASKS,${DL_DIR},1G,100K \
197 STOPTASKS,${SSTATE_DIR},1G,100K \
198 STOPTASKS,/tmp,100M,100K \
199 ABORT,${TMPDIR},100M,1K \
200 ABORT,${DL_DIR},100M,1K \
201 ABORT,${SSTATE_DIR},100M,1K \
202 ABORT,/tmp,10M,1K"
203
204#
205# Shared-state files from other locations
206#
207# As mentioned above, shared state files are prebuilt cache data objects which can
208# used to accelerate build time. This variable can be used to configure the system
209# to search other mirror locations for these objects before it builds the data itself.
210#
211# This can be a filesystem directory, or a remote url such as http or ftp. These
212# would contain the sstate-cache results from previous builds (possibly from other
213# machines). This variable works like fetcher MIRRORS/PREMIRRORS and points to the
214# cache locations to check for the shared objects.
215# NOTE: if the mirror uses the same structure as SSTATE_DIR, you need to add PATH
216# at the end as shown in the examples below. This will be substituted with the
217# correct path within the directory structure.
218#SSTATE_MIRRORS ?= "\
219#file://.* http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \n \
220#file://.* file:///some/local/dir/sstate/PATH"
221
222
223#
224# Qemu configuration
225#
226# By default qemu will build with a builtin VNC server where graphical output can be
227# seen. The two lines below enable the SDL backend too. By default libsdl-native will
228# be built, if you want to use your host's libSDL instead of the minimal libsdl built
229# by libsdl-native then uncomment the ASSUME_PROVIDED line below.
230PACKAGECONFIG_append_pn-qemu-native = " sdl"
231PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
232#ASSUME_PROVIDED += "libsdl-native"
233
234# CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to
235# track the version of this file when it was generated. This can safely be ignored if
236# this doesn't mean anything to you.
237CONF_VERSION = "1"
diff --git a/conf/template.qemux86-64/bblayers.conf.sample b/conf/template.qemux86-64/bblayers.conf.sample
new file mode 100644
index 0000000..3ef85d8
--- /dev/null
+++ b/conf/template.qemux86-64/bblayers.conf.sample
@@ -0,0 +1,22 @@
1# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
2# changes incompatibly
3POKY_BBLAYERS_CONF_VERSION = "2"
4
5BBPATH = "${TOPDIR}"
6BBFILES ?= ""
7
8BBLAYERS ?= " \
9 ##OEROOT##/meta \
10 ##OEROOT##/meta-el-common \
11 ##OEROOT##/meta-el-nfv-access \
12 ##OEROOT##/meta-enea-virtualization \
13 ##OEROOT##/meta-enea-bsp-x86 \
14 ##OEROOT##/meta-intel \
15 ##OEROOT##/meta-openembedded/meta-oe \
16 ##OEROOT##/meta-openembedded/meta-networking \
17 ##OEROOT##/meta-openembedded/meta-filesystems \
18 ##OEROOT##/meta-openembedded/meta-python \
19 ##OEROOT##/meta-virtualization \
20 ##OEROOT##/meta-poky \
21 ##OEROOT##/meta-cloud-services/meta-openstack \
22 "
diff --git a/conf/template.qemux86-64/conf-notes.txt b/conf/template.qemux86-64/conf-notes.txt
new file mode 100644
index 0000000..8df5560
--- /dev/null
+++ b/conf/template.qemux86-64/conf-notes.txt
@@ -0,0 +1,3 @@
1Common targets are:
2 enea-image-nfv-access-guest
3 enea-image-nfv-access-guest-sdk
diff --git a/conf/template.qemux86-64/local.conf.sample b/conf/template.qemux86-64/local.conf.sample
new file mode 100644
index 0000000..1d9beaf
--- /dev/null
+++ b/conf/template.qemux86-64/local.conf.sample
@@ -0,0 +1,237 @@
1#
2# This file is your local configuration file and is where all local user settings
3# are placed. The comments in this file give some guide to the options a new user
4# to the system might want to change but pretty much any configuration option can
5# be set in this file. More adventurous users can look at local.conf.extended
6# which contains other examples of configuration which can be placed in this file
7# but new users likely won't need any of them initially.
8#
9# Lines starting with the '#' character are commented out and in some cases the
10# default values are provided as comments to show people example syntax. Enabling
11# the option is a question of removing the # character and making any change to the
12# variable as required.
13
14#
15# Machine Selection
16#
17# You need to select a specific machine to target the build with. There are a selection
18# of emulated machines available which can boot and run in the QEMU emulator:
19#
20#MACHINE ?= "qemuarm"
21#MACHINE ?= "qemuarm64"
22#MACHINE ?= "qemumips"
23#MACHINE ?= "qemumips64"
24#MACHINE ?= "qemuppc"
25#MACHINE ?= "qemux86"
26#MACHINE ?= "qemux86-64"
27#
28# There are also the following hardware board target machines included for
29# demonstration purposes:
30#
31#MACHINE ?= "beaglebone"
32#MACHINE ?= "genericx86"
33#MACHINE ?= "genericx86-64"
34#MACHINE ?= "mpc8315e-rdb"
35#MACHINE ?= "edgerouter"
36#
37# This sets the default machine to be qemux86 if no other machine is selected:
38MACHINE ?= "qemux86-64"
39
40#
41# Where to place downloads
42#
43# During a first build the system will download many different source code tarballs
44# from various upstream projects. This can take a while, particularly if your network
45# connection is slow. These are all stored in DL_DIR. When wiping and rebuilding you
46# can preserve this directory to speed up this part of subsequent builds. This directory
47# is safe to share between multiple builds on the same machine too.
48#
49# The default is a downloads directory under TOPDIR which is the build directory.
50#
51#DL_DIR ?= "${TOPDIR}/downloads"
52
53#
54# Where to place shared-state files
55#
56# BitBake has the capability to accelerate builds based on previously built output.
57# This is done using "shared state" files which can be thought of as cache objects
58# and this option determines where those files are placed.
59#
60# You can wipe out TMPDIR leaving this directory intact and the build would regenerate
61# from these files if no changes were made to the configuration. If changes were made
62# to the configuration, only shared state files where the state was still valid would
63# be used (done using checksums).
64#
65# The default is a sstate-cache directory under TOPDIR.
66#
67#SSTATE_DIR ?= "${TOPDIR}/sstate-cache"
68
69#
70# Where to place the build output
71#
72# This option specifies where the bulk of the building work should be done and
73# where BitBake should place its temporary files and output. Keep in mind that
74# this includes the extraction and compilation of many applications and the toolchain
75# which can use Gigabytes of hard disk space.
76#
77# The default is a tmp directory under TOPDIR.
78#
79#TMPDIR = "${TOPDIR}/tmp"
80
81#
82# Default policy config
83#
84# The distribution setting controls which policy settings are used as defaults.
85# The default value is fine for general Yocto project use, at least initially.
86# Ultimately when creating custom policy, people will likely end up subclassing
87# these defaults.
88#
89DISTRO ?= "enea"
90# As an example of a subclass there is a "bleeding" edge policy configuration
91# where many versions are set to the absolute latest code from the upstream
92# source control systems. This is just mentioned here as an example, its not
93# useful to most new users.
94# DISTRO ?= "poky-bleeding"
95
96#
97# Package Management configuration
98#
99# This variable lists which packaging formats to enable. Multiple package backends
100# can be enabled at once and the first item listed in the variable will be used
101# to generate the root filesystems.
102# Options are:
103# - 'package_deb' for debian style deb files
104# - 'package_ipk' for ipk files are used by opkg (a debian style embedded package manager)
105# - 'package_rpm' for rpm style packages
106# E.g.: PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk"
107# We default to rpm:
108PACKAGE_CLASSES ?= "package_deb"
109
110#
111# SDK/ADT target architecture
112#
113# This variable specifies the architecture to build SDK/ADT items for and means
114# you can build the SDK packages for architectures other than the machine you are
115# running the build on (i.e. building i686 packages on an x86_64 host).
116# Supported values are i686 and x86_64
117#SDKMACHINE ?= "i686"
118
119#
120# Extra image configuration defaults
121#
122# The EXTRA_IMAGE_FEATURES variable allows extra packages to be added to the generated
123# images. Some of these options are added to certain image types automatically. The
124# variable can contain the following options:
125# "dbg-pkgs" - add -dbg packages for all installed packages
126# (adds symbol information for debugging/profiling)
127# "dev-pkgs" - add -dev packages for all installed packages
128# (useful if you want to develop against libs in the image)
129# "ptest-pkgs" - add -ptest packages for all ptest-enabled packages
130# (useful if you want to run the package test suites)
131# "tools-sdk" - add development tools (gcc, make, pkgconfig etc.)
132# "tools-debug" - add debugging tools (gdb, strace)
133# "eclipse-debug" - add Eclipse remote debugging support
134# "tools-profile" - add profiling tools (oprofile, lttng, valgrind)
135# "tools-testapps" - add useful testing tools (ts_print, aplay, arecord etc.)
136# "debug-tweaks" - make an image suitable for development
137# e.g. ssh root access has a blank password
138# There are other application targets that can be used here too, see
139# meta/classes/image.bbclass and meta/classes/core-image.bbclass for more details.
140# We default to enabling the debugging tweaks.
141EXTRA_IMAGE_FEATURES = "debug-tweaks"
142
143#
144# Additional image features
145#
146# The following is a list of additional classes to use when building images which
147# enable extra features. Some available options which can be included in this variable
148# are:
149# - 'buildstats' collect build statistics
150# - 'image-mklibs' to reduce shared library files size for an image
151# - 'image-prelink' in order to prelink the filesystem image
152# - 'image-swab' to perform host system intrusion detection
153# NOTE: if listing mklibs & prelink both, then make sure mklibs is before prelink
154# NOTE: mklibs also needs to be explicitly enabled for a given image, see local.conf.extended
155USER_CLASSES ?= "buildstats image-mklibs image-prelink"
156
157#
158# Runtime testing of images
159#
160# The build system can test booting virtual machine images under qemu (an emulator)
161# after any root filesystems are created and run tests against those images. To
162# enable this uncomment this line. See classes/testimage(-auto).bbclass for
163# further details.
164#TEST_IMAGE = "1"
165#
166# Interactive shell configuration
167#
168# Under certain circumstances the system may need input from you and to do this it
169# can launch an interactive shell. It needs to do this since the build is
170# multithreaded and needs to be able to handle the case where more than one parallel
171# process may require the user's attention. The default is iterate over the available
172# terminal types to find one that works.
173#
174# Examples of the occasions this may happen are when resolving patches which cannot
175# be applied, to use the devshell or the kernel menuconfig
176#
177# Supported values are auto, gnome, xfce, rxvt, screen, konsole (KDE 3.x only), none
178# Note: currently, Konsole support only works for KDE 3.x due to the way
179# newer Konsole versions behave
180#OE_TERMINAL = "auto"
181# By default disable interactive patch resolution (tasks will just fail instead):
182PATCHRESOLVE = "noop"
183
184#
185# Disk Space Monitoring during the build
186#
187# Monitor the disk space during the build. If there is less that 1GB of space or less
188# than 100K inodes in any key build location (TMPDIR, DL_DIR, SSTATE_DIR), gracefully
189# shutdown the build. If there is less that 100MB or 1K inodes, perform a hard abort
190# of the build. The reason for this is that running completely out of space can corrupt
191# files and damages the build in ways which may not be easily recoverable.
192# It's necesary to monitor /tmp, if there is no space left the build will fail
193# with very exotic errors.
194BB_DISKMON_DIRS = "\
195 STOPTASKS,${TMPDIR},1G,100K \
196 STOPTASKS,${DL_DIR},1G,100K \
197 STOPTASKS,${SSTATE_DIR},1G,100K \
198 STOPTASKS,/tmp,100M,100K \
199 ABORT,${TMPDIR},100M,1K \
200 ABORT,${DL_DIR},100M,1K \
201 ABORT,${SSTATE_DIR},100M,1K \
202 ABORT,/tmp,10M,1K"
203
204#
205# Shared-state files from other locations
206#
207# As mentioned above, shared state files are prebuilt cache data objects which can
208# used to accelerate build time. This variable can be used to configure the system
209# to search other mirror locations for these objects before it builds the data itself.
210#
211# This can be a filesystem directory, or a remote url such as http or ftp. These
212# would contain the sstate-cache results from previous builds (possibly from other
213# machines). This variable works like fetcher MIRRORS/PREMIRRORS and points to the
214# cache locations to check for the shared objects.
215# NOTE: if the mirror uses the same structure as SSTATE_DIR, you need to add PATH
216# at the end as shown in the examples below. This will be substituted with the
217# correct path within the directory structure.
218#SSTATE_MIRRORS ?= "\
219#file://.* http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \n \
220#file://.* file:///some/local/dir/sstate/PATH"
221
222
223#
224# Qemu configuration
225#
226# By default qemu will build with a builtin VNC server where graphical output can be
227# seen. The two lines below enable the SDL backend too. By default libsdl-native will
228# be built, if you want to use your host's libSDL instead of the minimal libsdl built
229# by libsdl-native then uncomment the ASSUME_PROVIDED line below.
230PACKAGECONFIG_append_pn-qemu-native = " sdl"
231PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
232#ASSUME_PROVIDED += "libsdl-native"
233
234# CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to
235# track the version of this file when it was generated. This can safely be ignored if
236# this doesn't mean anything to you.
237CONF_VERSION = "1"
diff --git a/images/build-qcow-image.inc b/images/build-qcow-image.inc
new file mode 100644
index 0000000..deace60
--- /dev/null
+++ b/images/build-qcow-image.inc
@@ -0,0 +1,10 @@
1inherit image-vm
2IMAGE_FSTYPES += "qcow2"
3
4# To reduce storage size remove the intermediate images
5do_clean_unused_img() {
6 rm ${IMGDEPLOYDIR}/*.hdddirect
7 rm ${IMGDEPLOYDIR}/*.ext4
8}
9
10addtask clean_unused_img after do_vmimg before do_image_complete
diff --git a/images/enea-image-nfv-access-common.inc b/images/enea-image-nfv-access-common.inc
new file mode 100644
index 0000000..453d152
--- /dev/null
+++ b/images/enea-image-nfv-access-common.inc
@@ -0,0 +1,13 @@
1require images/enea-image-common.inc
2
3IMAGE_INSTALL += " \
4 packagegroup-enea-virtualization \
5 kernel-modules \
6 "
7
8IMAGE_FSTYPES = "ext4.gz"
9
10#keep only the archive
11do_image_ext4_append() {
12 rm ${IMGDEPLOYDIR}/*.ext4
13}
diff --git a/images/enea-image-nfv-access-guest-sdk.bb b/images/enea-image-nfv-access-guest-sdk.bb
new file mode 100644
index 0000000..0e909b1
--- /dev/null
+++ b/images/enea-image-nfv-access-guest-sdk.bb
@@ -0,0 +1,13 @@
1DESCRIPTION = "Image for the guest side of the Enea NFV Access Platform"
2
3require images/enea-image-nfv-access-common.inc
4
5IMAGE_INSTALL += " \
6 packagegroup-enea-virtualization-guest \
7 packagegroup-enea-virtualization-tools \
8 kernel-devsrc \
9 "
10
11IMAGE_FEATURES += "dbg-pkgs dev-pkgs"
12
13require images/build-qcow-image.inc
diff --git a/images/enea-image-nfv-access-guest.bb b/images/enea-image-nfv-access-guest.bb
new file mode 100644
index 0000000..2317e23
--- /dev/null
+++ b/images/enea-image-nfv-access-guest.bb
@@ -0,0 +1,9 @@
1DESCRIPTION = "Image for the guest side of the Enea NFV Access Platform"
2
3require images/enea-image-nfv-access-common.inc
4
5IMAGE_INSTALL += " \
6 packagegroup-enea-virtualization-guest \
7 "
8
9require images/build-qcow-image.inc
diff --git a/images/enea-image-nfv-access-host-common.inc b/images/enea-image-nfv-access-host-common.inc
new file mode 100644
index 0000000..f3c673a
--- /dev/null
+++ b/images/enea-image-nfv-access-host-common.inc
@@ -0,0 +1,12 @@
1require images/enea-image-nfv-access-common.inc
2
3IMAGE_INSTALL += " \
4 packagegroup-enea-virtualization-host \
5 "
6
7IMAGE_FSTYPES += "tar.gz"
8
9# Due to a legacy include from corei7 machine we need to stop building following images
10NOHDD = "1"
11NOISO = "1"
12INITRD_IMAGE_LIVE = ""
diff --git a/images/enea-image-nfv-access-host-odm.bb b/images/enea-image-nfv-access-host-odm.bb
new file mode 100644
index 0000000..d325588
--- /dev/null
+++ b/images/enea-image-nfv-access-host-odm.bb
@@ -0,0 +1,3 @@
1DESCRIPTION = "Image for the host side of the Enea NFV Access Platform that provides ODM support"
2
3require enea-image-nfv-access-host.bb
diff --git a/images/enea-image-nfv-access-host-openstack.bb b/images/enea-image-nfv-access-host-openstack.bb
new file mode 100644
index 0000000..3429c94
--- /dev/null
+++ b/images/enea-image-nfv-access-host-openstack.bb
@@ -0,0 +1,17 @@
1DESCRIPTION = "Image for the host side of the Enea NFV Access Platform that provides Oopenstack support"
2
3require images/enea-image-nfv-access-host-common.inc
4
5IMAGE_INSTALL = " \
6 packagegroup-core-boot \
7 packagegroup-cloud-compute \
8 packagegroup-cloud-debug \
9 packagegroup-cloud-extras \
10 "
11
12IMAGE_FEATURES += "ssh-server-openssh"
13
14inherit openstack-base
15inherit monitor
16
17IMAGE_ROOTFS_EXTRA_SPACE_append += "+ 3000000"
diff --git a/images/enea-image-nfv-access-host-sdk.bb b/images/enea-image-nfv-access-host-sdk.bb
new file mode 100644
index 0000000..add2689
--- /dev/null
+++ b/images/enea-image-nfv-access-host-sdk.bb
@@ -0,0 +1,18 @@
1DESCRIPTION = "Image for the host side of the Enea NFV Access Platform"
2
3require images/enea-image-nfv-access-common.inc
4
5IMAGE_INSTALL += " \
6 packagegroup-enea-virtualization-host \
7 packagegroup-enea-virtualization-tools \
8 kernel-devsrc \
9 "
10
11IMAGE_FEATURES += "dbg-pkgs dev-pkgs"
12
13IMAGE_FSTYPES += "tar.gz"
14
15# Due to a legacy include from corei7 machine we need to stop building following images
16NOHDD = "1"
17NOISO = "1"
18INITRD_IMAGE_LIVE = ""
diff --git a/images/enea-image-nfv-access-host.bb b/images/enea-image-nfv-access-host.bb
new file mode 100644
index 0000000..0f5faae
--- /dev/null
+++ b/images/enea-image-nfv-access-host.bb
@@ -0,0 +1,3 @@
1DESCRIPTION = "Image for the host side of the Enea NFV Access Platform"
2
3require images/enea-image-nfv-access-host-common.inc