pelagicore/meta-pelux

PELUX is an open source, GENIVI compliant development platform that supports the Qt Automotive Suite

meta-pelux

A Yocto/OpenEmbedded layer providing PELUX images. PELUX is a Linux based platform used for developing automotive infotainment projects.

The layer provides the PELUX distro that is derived from poky. Furthermore, this layer provides core-image-pelux recipes, along with necessary additions to software components to enable a functional In-Vehicle Infotainment (IVI) base image. The software component additions and appendments found in this layer are specific for the PELUX image but can be used outside of this context.

Maintained at https://github.com/pelagicore/meta-pelux

Dependencies

This layer depends on:

meta layer	git repo
poky	https://git.yoctoproject.org/git/poky
meta-openembedded	http://cgit.openembedded.org/meta-openembedded
meta-virtualization	https://git.yoctoproject.org/git/meta-virtualization
meta-bistro	https://github.com/pelagicore/meta-bistro
meta-swupdate	https://github.com/sbabic/meta-swupdate

The relationship with meta-bistro, which is also developed at Pelagicore, is that meta-bistro contains general software recipes and configurations, aimed at the IVI domain, but no distribution and no images, whereas meta-pelux builds on top of meta-bistro by adding a distro and recipes to build complete system images.

Branching

This repository will follow the Yocto release system. Whenever a new Yocto release has been released, a new branch with the same name will be created from the master branch.

All feature growth should happen first on the master branch, but will also be cherry-picked back to the latest Yocto release branch. Security and bug fixes will be evaluated case by case and backported as necessary. The ambition is to actively maintain the two latest releases and/or one-year-old releases in this fashion.

License and Copyright

Copyright © 2016-2017 Pelagicore AB
Copyright © 2017-2019 Luxoft Sweden AB

All metadata is MIT licensed unless otherwise stated. Source code included in tree for individual recipes is under the LICENSE stated in the associated recipe (.bb file) unless otherwise stated.

License information for any other files is either explicitly stated or defaults to MIT license.

meta-pelux's Issues

[Q] Qt Creator version & wayland RPI image

I try to use the Pelux 3.0 SDK for Raspberry Pi3, based on the documentation https://pelux.io/software-factory/master/swf-blueprint/docs/articles/sdk/configure-qtcreator.html

Installation process was understandable and successful, but the following points I cannot execute shown here: https://stackoverflow.com/questions/54810715/setup-pelux-3-0-raspberry-pi-3-kit-qtcreator-cmake-error-unknown-option

I saw RPI image is forced to single process of neptune ui 3 and when I connect through ssh to RPI, then I see only one process in top.

1. Is Wayland active?
2. How I can confirm, that wayland is active?

Make softwarecontainer optional by using a distro feature

By making a distro feature for softwarecontainer, and thus making it optional for inclusion, we no longer have to rely on meta-virtualization. meta-virtualization depends on meta-python, meta-filesystems and meta-networking - so we would remove 4 required layers for PELUX users not needing softwarecontainer if we make it optional.

Current softwarecontainer inclusion is here:

meta-pelux/recipes-core/images/core-image-pelux.bb

Line 11 in 3b80b2b

IMAGE_INSTALL += "softwarecontainer"

[Q] Compatibility with Qt commercial qtcreator

I'm trying to test if I can make app with qtcreator and install via appman to the pelux.
I installed qtcreator(commercial trial) which provides 'automotive suites examples'.

First of all, I configured the pelux toolchain kit (for rpi-auto) as described in pelux doc
Then I selected a example in the qtcreator, which named 'hello-world'.
The sample just has only qml files without native C/C++ file.
Since the sample consists of qml files only, it doesn't need link step. But generated Makefile by qmake has the following line.

$(TARGET):  $(OBJECTS)  
    $(LINK) $(LFLAGS) -o $(TARGET) $(OBJECTS) $(OBJCOMP) $(LIBS)

However if I did with pre-existing automotive-suite toolchain included in the qt installer (for intel NUC), the generated Makefile was slight different.

hello-world:  $(OBJECTS)  
    

Eventually, it fails on 'link' step when I try with pelux toolchain. But with 'intel NUC' automotive-toolchain, there is no issue.

Do you know why different Makefiles are created based on the same qmake project file?

Move PELUX BSP layers into this layer, as sub-layers

This ticket is meant to create a discussion around moving the PELUX BSP layers for Raspberry Pi and Intel into the meta-pelux layers.

There are several benefits of doing so:

• It seems to be best practice, when looking at other layers (poky: http://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto/tree/meta-yocto-bsp)
• It will reduce the number of dependencies (meta-pelux no longer needs to depend on meta-pelux-bsp-intel, because this is merged in to the same repo, for instance)
• It will be easier to keep the BSP adaptions and the main layer in sync

Potential drawbacks:

• It is not possible to use the BSP adaptions separately from PELUX (although, is this ever an intended use-case?)
• We will get more traffic in the main git repo (although the BSP layers don't have much traffic currently)

What are your thoughts?

Change default install path from /opt to ~/sdk

Most of the users which install the SDK haven't prepared their system to allow the user to install things into /opt. /opt is the default install path for the SDK but should be changed to ~/sdk

Add support for kdump

Debugging kernel crashes would be much easier if we had kdump support in the kernel & in systemd.

Basically, we would need to:

• Configure the kernel with kdump, kexec and debug support (see 1)
• Configure persistent bootloader settitings for the crashkernel parameter (depends on which bootloader we use)
• Create systemd unit for loading backup kernel using kexec (see 1)

Issues to consider

Always enabbling kdump may cause performance issues, so maybe we want to enable it only on debug images.

meta-qt5 should only be in bblayers if building with QtAS

For some reason, meta-qt5 is in pelux-base.xml. It should be in pelux-qt.xml. The bblayers.conf should be updated accordingly, so that the layer is only included if building the QtAS version of PELUX

Useless patch left in the layer

I'm a bit confused by the existence of: layers/poky/patch/0001-Fix-automated-runtime-testing-using-SystemdbootTarge.patch
It looks like the patch doesn't apply on top of poky anymore and I have been able to run automated tests without using this patch. Does anyone know if it's necessary for anything? Should we re-work this patch or remove it?

module "QZXing" is not installed in qml @ pelagicore/meta-pelux

Change SDK name from oecore to pelux

Right now when you create a SDK it is named something like oecoretoolchainsh, this should be changed so it is instead peluktoolchainsh

Upstream neptuneui patch

The neptune.bbappend file contains fixes that should be upstreamed to boot2qt

qtapplicationmanager.bbappend: libsoftwarecontainer-plugin breaks the nativesdk build

The nativesdk build is broken as the bbappend assumes that the examples are built even for the -config tools-only version.

Furthermore, I am questioning whether this bbappend should be included in PELUX by default. This plugin was made as an example implementation by Robert and I am not sure would it be sensible to use it as a project would need to create it's own variant as far as I know. Please discuss :)

[Q] appman-controller

I do not know if this is the right place to leave a question.
If the right place exists separately, please let me know.

The question is that whether I can use appman-controller command on the pelux.

I just tried to list the installed apps up by the following command, but it failed with an error.

$ appman-controller list-applications

ERROR: Could not find the D-Bus interface of a running Application-Manager instance.
(did you start the appman with '--dbus none'?

appman seems to be working fine, which connects to the dbus session bus.

207 root       0:13 /usr/bin/appman -r -c am-config.yaml --dbus session -platform eglfs -c /opt/am/sc-config.yaml

To check DBUS_SESSION_BUS_ADDRESS

$ strings /proc/207/environ 
PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
INVOCATION_ID
0e4c592333ac4531aa6a65b67dc16f02
JOURNAL_STREAM
8:7050
HOME
/home/root/
LC_ALL
en_US
DBUS_SESSION_BUS_ADDRESS
unix:path=/run/user/root/dbus/user_bus_socket
QT_IM_MODULE
qtvirtualkeyboard
XDG_RUNTIME_DIR
/tmp
QT_WAYLAND_HARDWARE_INTEGRATION
brcm

I tried by setting DBUS_SESSION_BUS_ADDRESS env variable, but the result was the same as before.

$ export DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/root/dbus/user_bus_socke"
$ appman-controller list-applications

ERROR: Could not find the D-Bus interface of a running Application-Manager instance.
(did you start the appman with '--dbus none'?

Make core-image-pelux into a bbclass

This will allow us to "inherit core-image-pelux" in PELUX-based images.

See for example how "core-image" works in relation to, for example, "core-image-minimal":

core-image: https://github.com/openembedded/openembedded-core/blob/master/meta/classes/core-image.bbclass
core-image-minimal: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/images/core-image-minimal.bb?h=master

Remove dependency on meta-template

I don't think it should be a required layer for all PELUX-based projects, since the template-service provided might not be used by all projects.

Dependency introduced here:

meta-pelux/recipes-core/images/core-image-pelux.bb

Line 15 in 3b80b2b

IMAGE_INSTALL += "template-service"

Remove dependency on boot2qt

The bbappends in recipes-qt/automotive introduce a dependency to boo2qt.

You can't build w/o the dangling bbappends option enabled. - Can we move these bbappends somewhere else, or include them in the layer only when the boot2qt layer is enabled?