Pelux is build on top of multiple sources, they are described on an
xml file called
In order to clone all the sources at once,
repo is used.
Create a directory for the PELUX build. On that directory, run
repo init, and it will create a
.repo directory which will later be used for fetching the sources.
repo sync to fetch all sources on a new directory called sources.
# Initialize repo on the given repository repo init -u https://github.com/Pelagicore/pelux-manifests.git #Fetch the sources based on the .repo directory repo sync
Now all the repositories required for building PELUX have been cloned under
A note on image types¶
PELUX images are available with the -dev suffix, which include some extra development and debugging tools. Images are also available as -update to generate update artifacts for the SOTA System. The -dev and -update images can also be merged to build -dev-update which includes both features on the image.
It should be noted that the regular image is not a production ready image. For a production project, it is recommended to create an image that can be based on the PELUX image to begin with, but one will probably want to create a custom image eventually, as the project evolves further and further away from vanilla PELUX. For example, a PELUX-based image has an empty root password and an ssh server installed by default.
Pelux can be build for intel, arp, rpi, and qemu. Our variants are dependent on the target we are building for.
If the variant contains only the target, a minimal image will be available to be built with no graphics layer. If the variant contains the target name, and the suffix
-qtauto, the minimal image will be available to be build as well as the image containing Qt Automotive.
The only variant which does not offer a graphical UI is QEMU.
All the variants set different configurations, therefore it is important to specify the correct variant before sourcing for bitbake.
When sourcing, you can tell the
oe-init-build-dev script, to use a specific directory for configuration of a variant.
TEMPLATECONF tells the
oe-init-build-env script which path to fetch
configuration samples from.
TEMPLATECONF=`pwd`/sources/meta-pelux/conf/variant/<VARIANT-NAME> source sources/poky/oe-init-build-env build
The script will create configurations if there are no configurations present. A printout about
conf/bblayers.conf is normal.
We support intel, ARP and raspberry pi builds. The qt-auto layer can be found on all of them.
Once you have synced the repo, run the following to configure the environment for Qt Automotive images.
# For intel-qtauto: TEMPLATECONF=`pwd`/sources/meta-pelux/conf/variant/intel-qtauto source sources/poky/oe-init-build-env build # For rpi-qtauto: TEMPLATECONF=`pwd`/sources/meta-pelux/conf/variant/rpi-qtauto source sources/poky/oe-init-build-env build # For arp-qtauto: TEMPLATECONF=`pwd`/sources/meta-pelux/conf/variant/arp-qtauto source sources/poky/oe-init-build-env build
rpi-qtauto variants, we support the following images:
Qt Automotive + Neptune 3 UI images¶
In case you want to build only the pelux base image, that can be done by removing qtauto suffix from the variant name.
# For intel: TEMPLATECONF=`pwd`/sources/meta-pelux/conf/variant/intel source sources/poky/oe-init-build-env build # For rpi: TEMPLATECONF=`pwd`/sources/meta-pelux/conf/variant/rpi source sources/poky/oe-init-build-env build # For arp: TEMPLATECONF=`pwd`/sources/meta-pelux/conf/variant/arp source sources/poky/oe-init-build-env build
rpi variants, we support the following images:
Building the image¶
Finally, build the desired image. See the variables description above for information on the different images.
When the build is complete the result will be available in
tmp/deploy/images/<machine>/. It is possible to generate a number of
different image formats, ranging from just the rootfs as a tarball to ready
disk-images containing EFI-bootloader, configuration and rootfs and that can be
written directly to a storage device. For PELUX, the preferred format for the
Intel NUC are
.wic images, which are complete disk-images. For the Raspberry
Pi 3, the preferred format is
.rpi-sdimg which can be directly written to
the SD card.
Building with Vagrant¶
In the current setup in our CI system we use Docker with Vagrant, however only in a GNU/Linux system. It should still work under Windows or OSX, but we have not tried it.
- Docker CE
- Virtualization enabled in BIOS
Ubuntu and Debian both have very old versions of Docker in their apt repositories. Follow the steps at docker.io to install the latest version of Docker.
- Clone the pelux-manifests git repository with submodule
git clone --recurse-submodules firstname.lastname@example.org:Pelagicore/pelux-manifests.git
- Start Docker through Vagrant
docker build -t pelux . docker run -d --name pelux-build -v $(pwd):/docker pelux
- Run inside the Docker container
At this point, we recommend using
vagrant ssh and to follow the same
instructions as when building locally (but inside the Docker container).
- Move the built images to the host
The directory where you cloned pelux-manifests is bind-mounted to
inside the container, so you can simply run:
cp <YOCTO_DIR>/build/tmp/deploy/images /vagrant
For more detailed steps, refer to the
where we have automated our building of PELUX.