source : IoT.bzh (as of 2015/10/13)

Original document : Audit_on_GENIVI_components_in_AGL_Phase-1.pdf

Appendix : Audit_on_GENIVI_components_in_AGL_Phase-1_ANNEX.pdf

Early 2014, AGL chose Tizen IVI as the reference distribution for its Automotive Software Stack.

In mid-2014, thus during the same time frame, was announced the “Tizen on Yocto” project, which intended to bring the flexibility of Yocto to the Tizen distribution.

GENIVI then distributed its reference software as a Yocto layer, directly hosted at the Yocto project homepage.

In 2015 though, visible progress on Tizen IVI slowed down. Finally no definitive merge between GENIVI packages, Tizen IVI and Yocto happened before the last known Tizen IVI release.

In this document, we present an analysis of AGL/Phase 1 regarding GENIVI components and propose a strategy to integrate GENIVI and other projects smoothly into AGL.

For this study, the following Git repositories have been considered :

• GENIVI 8.0 - meta-ivi layer (branch '8.0')
• GENIVI demo layer
• Tizen IVI 3.0 final (tag 'rev_ivi_2015_02_04')
• Poky 1.7 'Dizzy'
• OpenEmbedded 1.7 'Dizzy'

There were discussions in August 2015 about the OS/Common Libs recipes development and how to integrate GENIVI layers into AGL (see also here and here).

An analysis has been done to identify packages impacted by the GENIVI layer. The list contains 19 packages (systemd packages were excluded).

[1] : maintained in Poky, but not the default version
[2] : forked and maintained in GENIVI

Another analysis has been posted on the AGL mailing list. This last one was used as an alternative source of information. Following is a raw copy of posted document on AGL mailing list :

Recent GNU software tends to use the GPLv3 license, which compared to former GPLv2, adds some addtional constraints onto software distribution. Such restrictions are often considered as an issue for derived proprietary embedded systems. For a detailed description of potential issues, please read this.

Instructions for building the older 6.0.0 GENIVI release contained an explicit mention to prohibit the use of GPLv3.

Tizen IVI had no such restriction.

As a result, some packages differ as they are kept at their older GPLv2 revisions. They are currently :

• Bash
• Gawk
• Coreutils
• Gettext

Bash, Gawk and Coreutils are merely tools, and can easily be replaced. Gettext, on the other hand, is a widely-used internationalization library with ramifications deep inside the system.

Please aslo note that these dependencies impact the following package :

• Parted

Side notes : As a side note, recent GENIVI build instructions do not contain the GPLv3 mention anymore. Does this mean that GENIVI now allows GPLv3 packages ? A formal clarification on GPL licensing policies would be more than welcome.

Suggestions : Whether GENIVI would allow GPLv3, it would then be possible to switch to more recent versions of many packages (except for Gettext). If it does not, then we have to keep these older versions until a suitable replacement is found. Potential replacements include :

• Bash : Dash - ksh
• Gawk : BWK awk
• Coreutils : Toybox
• Parted : GPT fdisk

Tizen Yocto was supposed to align all its packages versions with Yocto 1.7. There is only one package which does not comply :

• Fuse

The Tizen IVI version is a bit older. As there is no technical explanation, this is most likely to be a mistake or an oversight. Updating should be straightforward.

Suggestions : Stick to the Yocto/OpenEmbedded version.

Yocto provides two packages with applied patches, making them differ from Tizen IVI :

• Unzip
• Libarchive

The patches are security fixes, one of which (CVE 2015-1315 for Unzip) was released subsequently to TIzen IVI's latest release (mid-February 2015). Using these Yocto-patches versions is a no-brainer.

Suggestions : Keep the Yocto versions, with custom patches.

There are some packages which simply do not have any correspondence between distributions. This mostly happens for “administrative” packages (i.e. used for compilation or production of the final image) or for strategical reasons.

• Procps-ng : “procps” is the traditional package providing /proc-related command-line tools (ps, top, skill…). However, it has not been updated for years and requires lots of custom patches for today's uses ; hence why Tizen IVI prefers to use its “procps-ng” fork instead.

Yocto 1.7, though, unfortunately does not provide this package.

Suggestions : Keep the Tizen IVI version, store it in the AGL tree, and submit it to the upstream Yocto project meanwhile. This way, future AGL releases may be able to use Procps-ng directly without maintaining the packaging.

• Quota
• Libcgroup
• Tcp-wrappers
• Os-release
• Volatile-binds

Out of these 5 packages, 1 is a command-line tool (“quota”), 1 an application library (“libcgroup”) and the last 3 (“tcp-wrappers”, “os-release”, “volatile-binds”) are Yocto-specific administrative packages.

• “Quota” permits to put size restrictions on users' profiles. This feature was not implemented in latest Tizen IVI (multi-user had just been implemented in Tizen 3.0) but can prove itself useful in a near future and should be straightforward to integrate.
• “Libcgroup” permits applications to easily manipulate kernel Control Groups ; it could be useful to control/isolate applications on embedded systems.
• “tcp-wrappers”, “os-release” and “volatile-binds” are administrative packages used mostly for OS image preparation and boot. For instance, “os-release” customizes the “/etc/os-release” file, used by most tools to identify the distribution ; Tizen IVI does it too, but in its “tizen-release” package.

Suggestions : Keep “quota”, “libcgroup” and “os-release” from Yocto 1.7. Remove use of “tcp-wrappers” and “volatile-binds” until it proves itself useful. “os-release” could be replaced by a specific package named “agl-release”.

GENIVI also maintains a publicly-accessible repository of Yocto recipes, supposed to be used on top of Yocto (as an additional layer).

Here is a list of these recipes, and what they contain and related to.

These recipes do not exist in Yocto.

For reference, we used the following extraction command:

# find meta-ivi -name *.bb | egrep -v "(packagegroup|recipes-yocto-ivi)" | xargs -n 1 basename | sort

The following package already exist in Yocto/OpenEmbedded, and are modified by the meta-ivi layer :

For reference, we used the following extraction command :

# find meta-ivi -name *.bbappend | xargs -n 1 basename | sort

Most of the non-Yocto (“specific”) packages implement parts of the AGL 1.0 specification, for which there is no notable implementation in the upstream field nor in Tizen IVI.

Concerned sections of the specification are studied further below (see [AGL 1.0 specification matching]), but here is a short summary :

• audiomanager : Sound Manager (AGL§4.1.4)
• dlt-daemon : Diagnostic Services (AGL§5.2.4)
• layer-management - wayland-ivi-extension : Window Manager (AGL§4.1.2)
• node-health-monitor : Health Monitoring (AGL§5.1.5)
• node-startup-controller - *-state-controller : Lifecycle Management (AGL§5.1.7)
• persistence-administrator - *-client-library - *-common-object : Persistent Storage (AGL§5.1.5)

Among already existing packages, some are also patched to match the AGL specification :

• weston_1.5.0.bbappend : add IVI-Shell = Window Manager (AGL§4.1.2)

Most of the existing Yocto packages reimplemented in the GENIVI layer have patches serving the following purposes :

• gstreamer1.0-plugins-bad - neard - ofono - pulseaudio : switch from bluez4 to bluez5
• qt4-embedded : enable the QML/Qt graphical widget definition language
• … and other negligible things.

As Yocto provides a basis for a working (embedded) operating system, and the most recent versions of Tizen IVI and GENIVI are based on it, there is no need to duplicate its work. In other words : basic and not-to-be-modified packages such as “glibc”, “zlib”… can be pulled from Yocto directly, without any involvement besides adding contextual patches.

This will also allow maintainers to focus on integration tasks for RENESAS and GENIVI compliance. This mainly consists in :

• RENESAS-specific work (kernel modules for BSP support) ;
• IVI packges, consisting of packages pulled from either Tizen IVI or GENIVI Legacy (IVI-Shell, Automotive Message Broker …).

In this respect, the team should actively :

• push new packages for upstream integration (e.g. RENESAS BSP support inside Yocto/OpenEmbedded, procps-ng support inside Poky…) so that their maintenance cost decreases over time ;
• for packages out of place on upstream channels (ex : IVI-specific software such as Automotive Message Broker, ICO…), maintain them on a third-party repository providing additional Yocto layers.

Next sections will detail how this could be done.

Yocto allows to extend existing recipes by using .bbappend files.

The user should be instructed to download a Yocto-Poky 1.7 stable release, and have instructions to download the additional RENESAS Yocto layers as easily as possible.

These layers should not, if possible, alter the underlying Poky distribution. They should fit nicely “on top” of it.

If those layers provide an alternative for a Poky package (for instance, “procps-ng” instead of “procps”), they should provide a .bbappend and a .conf rule so that the alternative gets picked up instead of the Poky one.

If those layers provide a patch for a Poky package, they should provide a .bbappend rule so that the patch gets applied when necessary.

Then, by a single group of commands, the uses should be able to compile the software and create a flashable image containing RENESAS and GENIVI components.

Nevertheless, some of these components, such as drivers, are binary-only due to licensing concerns. In this case, the components should be downloaded in their binary format from a RENESAS or team repository.

The final image should contain all software necessary to boot the RENESAS R-Car board, with graphics, sound… and comply with the AGL specification.

It is the responsibility of maintainers to write the documentation and do the integration related to this.

1) Merge former 19 packages depending on conclusion of first analysis (see [SECTION] for results);

2) Compare full list of current Yocto 1.7 and Tizen IVI packages. Notice the gaps, identify their motivations as in the first analysis and merge as in 1) (see Appendix for results);

3) Host the result on an accessible repository.

1) Merge GENIVI packages depending on conclusion of first analysis (see [SECTION2] for results);

2) Compare full list of current Yocto 1.7 and Tizen IVI packages. Notice the gaps, identify their motivations as in the first analysis and merge as in 1) (see Appendix for results);

3) Host the result on an accessible repository.

1) Validate that RENESAS BSP layers can be added on top of Poky 1.7. Modify or create new rules (.bbappend, .conf files) if necessary. Push patches to upstream Poky if necessary ;

2) Test on R-Car board(s) ;

3) Host the whole layers on an online repository ;

4) Write instructions on how to generate the final image using this repository.

(see appendix “Audit on GENIVI's components in AGL_Phase-1-ANNEX”)

Listing all packages present in Tizen IVI, and comparing them with Yocto 1.7, gives the following result :

• Total Tizen packages : 305
• Tizen Common-specific packages : 90
• Tizen IVI-specific packages : 17
• Upstream packages, not synchronized Poky <> Tizen : 58
• Upstream packages, which exist in Tizen but not in Poky : 42

Hence the following status :

• Tizen has 305 - 90 - 17 = 198 upstream packages ;
• Among these 198 packages, 198 - 42 = 156 also exist in Yocto ;
• Among these 156 packages, 156 - 58 = 98 are synchronized.

We can then propose two strategies depending on package types.

There are 42 upstream packages, having public websites and/or repositories, not present in Yocto. Are they necessary ? If they are, they should be pushed to upstream Yocto.

Here are some examples :

• ibus : internationalization helper library

Mostly needed by weekeyboard (EFL virtual keyboard) : do we need an alternative Wayland virtual keyboard ? Weston already provides one. If not, no work is needed.

• iniparser : general-purpose configuration parser library

Not used by any important software, no work needed.

• libbullet : physics engine library

Mostly needed by recent EFL ; should be pulled when it becomes mandatory. Work needed.

• libinput : general-purpose input library (keyboard, mouse, touch…)

Will be needed by Weston >= 1.70, already present in recent Poky, work not needed.

• libva : GPU video acceleration support

Appreciably enhances video playback. Will a future version support our GPU ? If it will, work needed.

There are currently 58 packages in Tizen which are not in sync with their counterpart in Yocto 1.7.

Is there any ground for this ? If there is, patches and custom recipes should be maintained locally ; if not, we should synchronize with Yocto.

Here are some examples :

• bluez : hardware bluetooth support

Does our bluetooth hardware require the most recent version ? If it does, maintain locally.

• EFL : UI application framework

Do we need the more recent features, such as the pure-Wayland display manager ? If we do, maintain locally.

• mesa : graphics stack

Does our GPU require the the most recent version ? if it does, maintain locally.

• openssl : cryptographic library

Yocto version has the CVE-2014-3567/3568/3569 security vulnerabilities. Patch or maintain locally.

• libv4l : video4linux, hardware video capture support

Yocto has a more recent version, and supports our hardware. Sychronize with Yocto.

(see appendix “Audit on GENIVI's components in AGL_Phase-1-ANNEX”)

The final distribution should ideally be fully compliant with the AGL 1.0 specification. This includes features such as : Application framework, Web runtime with HTML5, Miracast compatibility, Policy Manager.

These features mostly live in non-upstream packages, part of Tizen Common or IVI, such as “crosswalk”, “automotive-message-broker”, “murphy”…

Hence follow some proposals :

1. Are these features supported in a GENIVI layer (see above) package ? If they are, we should simply use this package, and no further work is needed.
2. If they are not, is there an existing upstream package, included in Yocto, supporting these features ? If there are, we should list and compare them, and decide if adaptation work is needed.
3. If not, is there an existing Tizen Common/IVI package supporting these features ? If there are, we should list them, and decide if adaptation work is needed.

This chapter describes how to group the features by package types, then determine existing package names in GENIVI, upstream, and Tizen.

Here follows some of the AGL specification 1.0 points which can materialize as packages (the notation 'AGL§x.y.z' is used to reference an AGL specification 1.0 chapter).

Home Screen (AGL§3.1)

The specification requires a “customizable GUI layout”, defined with items such as “screen resource”, “input resource”, “transition effect”. (AGL§3.1.8.1)

Weston's ivi-shell provides a home screen without any specific automotive applications, fitting those needs. It is included starting from Weston 1.7, which is present in latest Yocto.

However, it also requires “sound resource” management, a “system setting menu”, a “mechanism to change date”, “change wireless communications”… (AGL§3.1.8.2).

For this, we need an enhanced home screen. GENIVI nor upstream do not provide one ; Tizen IVI, though, has 2 optional packages fitting this need : “Modello-Homescreen” (HTML5) and “ico-uxf-homescreen” (native). Note that these 2 packages are not maintained anymore, so we need to resume their maintenance.

Proposal : pull Weston ivi-shell from latest Yocto, pull ICO or Modello homescreen from Tizen IVI, and secure maintenance/development of these.

Window Manager (AGL§4.1.2)

The specification requires a “software component that is responsible for a layout management of windows” (this is satisfied by the standard “weston” package) but also which satisfies “IVI's complex requirements, typically requested from Policy Manager”.

The Use Case (AGL§4.1.2.1) then refers to Policy Manager's (see below) screen resource control section, which specifies :

• allocation of surfaces (position, size…) ;
• visibility control (surface visibility depending on driving mode e.g.) ;
• layer information (z-order…).

The GENIVI Yocto layer “meta-ivi” contains the “layer-management” and “wayland-ivi-extensions” packages, which fulfill these requirements.

Proposal : pull the “layer-management” and “wayland-ivi-extensions” package from GENIVI Yocto layer.

Policy Manager (AGL§4.1.3)

The specification requires a Policy Manager which will “collect lots of status, such as user operation and application status, then issue Vehicle Info Control or Resource Control” (AGL§4.1.3.1.1).

The detailed sections specify that it includes Screen (AGL§4.1.3.1.2.a), Sound (AGL§4.1.3.1.2.b), Input (AGL§4.1.3.1.2.c) resources, and precisely which resources.

A policy manager is specific to the IVI market, there are no well-known implementations upstream, nor does GENIVI provide one. Tizen IVI, though, had such a software called Murphy. Note that it's not much maintained anymore.

Proposal : pull Murphy from Tizen IVI, and security its maintenance/development.

Sound Manager (AGL§4.1.4)

The specification requires a Sound Manager which will “manage a mediation rule” when a “sound output demand in two or more zones from two or more zones from two or more applications is arbitraded”.

The GENIVI Yocto layer “meta-ivi” contains an audio-manager package, which server precisely this requirement.

Proposal : pull the GENIVI Yocto “audio-manager” package.

Web HMI (AGL§4.2)

The specification requires a web-based interface for the application framework, including a HTML5-based Web API (AGL§4.2.1) which must provide :

• a multimedia content selection API (with URL, predefined list…) ;
• a multimedia content browsing API (play, pause, rewind…) ;
• a volume control API (up, down, mute) ;
• a metadata access API for content (author, year…)
• a notification emission API ;
• an AM/FM radio playing API (frequency change, station info…);
• a digital radio playing API ;
• a vehicle information access API (fuel level, car model…) ;
• a speech-to-text/text-to-speech control API ;
• a navigation control API ;
• a peer-to-peer communication API for applications ;
• a W3C/HTML5 DOM, Forms and Style API ;
• a W3C/HTML5 Device API (touch event, screen orientation change event…) ;
• a W3C/HTML5 graphics API (canvas, SVG…) ;
• a W3C/HTML5 media API (audio/video tags…) ;
• a W3C/HTML5 communication API (web sockets, server events…) ;
• a W3C/HTML5 storage API (web storage, file storage, web SQL…) ;
• a W3C/HTML5 security API (cross-origin restriction, iframe restriction…) ;
• a W3C/HTML5 desktop UI API (clipboard access, drag-&-drop events…) ;
• a W3C/HTML5 performance API (timing control…) ;
• a W3C/HTML5 geolocation API ;
• a W3C/Widget API ;
• Khronos WebGL API.

In order to support all these APIs, a Web Runtime, which is a web application execution environment, is required (AGL§4.2.2). It provides :

• an access control mechanism ;
• GUI components (text labels, buttons, sliders, input forms…) ;

Neither Yocto, nor GENIVI have a ready-to-use web framework for this purpose. Tizen had webkit-efl and crosswalk (based upon Chromium) together with the tizen-extensions package, but they are tightly linked wih the Tizen Web API, which is slightly different from the AGL web API specification.

Proposal : find an alternative.

Native HMI (AGL§4.3)

The specification requires a native interface for the application framework, providing :

• GUI components (text labels, buttons, sliders, input forms…) ;

Neither Yocto, nor GENIVI have a ready-to-use native framework for this purpose. Tizen had the platform/core/api/ packages, but they are tightly linked with the Tizen API, which is slightly different from the AGL API specification.

Proposal : find an alternative.

Location Services (AGL§5.1.4)

The specification requires the presence of a GPS system, which will be used for geolocation as well as for time-of-day adjusting (AGL§5.1.4.2).

The OpenEmbedded Yocto layer provides the gpsd daemon. It is a well-known and functional GPS daemon implementation.

Proposal : use gpsd from Yocto/OpenEmbedded.

Health Monitoring (AGL§5.1.5)

The specification requires “platform monitoring services such as watchdog or active monitoring”.

The GENIVI Yocto layer (“meta-ivi”) provides a “node-health-monitor” package which addresses the requirement.

Proposal : pull the “node-health-monitor” package from GENIVI Yocto layer.

Persistent Storage (AGL§5.1.9)

The specification requires a “power-safe persistent storage” solution.

The GENIVI Yocto layer (“meta-ivi”) provides a “persistence-client-library” package which, together with “persistence-administrator” and “persistence-common-object”, fulfill this requirement.

Proposal : pull the “persistence-client-library” package from GENIVI Yocto layer.

Telephony Services (AGL§5.1.12)

The specification requires the presence of a phone system, which will support Bluetooth pairing (AGL§5.1.12.1.1).

Yocto 1.7 contains the ofono telephony daemon, as well as the bluez subsystem for Bluetooth hardware recognition and data transfer. Bluez may need enhancements or patches to work well with the board Bluetooth adapter.

Proposal : use the ofono and bluez packages from Yocto, eventually patch and upgrade bluez depending on hardware.

Miracast (AGL§5.1.13.1.2)

The specification requires a display sharing protocol, which is specifically named to be Miracast.

There is no well-known open-source implementation of Miracast, mostly due to royalty fees concerns. A proprietary stack named WiDi is available but was not shipped with Tizen IVI for this reason.

Proposal : find/choose an implementation.

DLNA (AGL§5.1.13.1.3)

The specification requires a digital media sharing protocol, which is specifcally named to be DLNA.

There is an open-source implementation of DLNA named dleyna, which is included in Yocto (0.4.0 in 1.7 as of writing).

Proposal : use the dleyna package from Yocto.

Camera Services (AGL§5.2.2)

The specification requires support for mounted cameras inside the vehicle.

Yocto includes a version of the v4l (Video4Linux) libraries, which enables hardware access to cameras, allowing recording, monitoring…

Proposal : use the v4linux-util package from Yocto.

Multimedia Server (AGL§5.2.5)

The specification requires support for a variety of multimedia formats : CD, DVD, Blu-Ray, MP3…

What's more, it also requires the presence of a Media Player (AGL§5.2.5.1), which is said, without much precision, to match “major end-user expectation”, support “multiple audio/video sources”… It further indicated that it should be able to extract data such as “subtitles”, support streaming protocols such as “HTTP”, “RTPS”, (AGL§5.2.5.2.1)…

Further text states support for containers such as “MPEG2-TS/PS”, “MP4” ; audio codecs such as “MP3” or “AAC” (AGL§5.2.5.2.2), video codecs such as “MPEG-2”, “MPEG-4 Part 2” (AGL§5.2.5.2.3), and image formats such as “JPEG” or “PNG” (AGL§5.2.5.2.4)…

Among Yocto packages, libav, which is a fork of the popular FFmpeg, provides such audio/video capabilities. Please note, however, that some codecs such as MP3 may suffer distribution restrictions depending on publication region, and thus may be disabled for development builds.

Proposal : use libav from Yocto. Provide Yocto configuration options to disable restricted codecs in development builds.

Personal Information Manager (AGL§5.2.7)

The specification requires a service able to centralize personal data : appointments, reminders…

Tizen used the “evolution-data-server” (eds) package together with libfolks for this purpose.

Proposal : use the evolution-data-server package from Tizen.

Smart Device Link (AGL§5.2.8.2)

The specification requires Smart Device Link capabilities, also known as remote control from a smartphone (for capable applications only).

There is no Yocto package implementing this ; Tizen IVI, though, contains a “smartdevicelink” package, which responds to the requirements.

Proposal : use smartdevicelink from Tizen IVI.

Speech Services (AGL§5.2.9)

The specification requires “voice recognition and synthesis”.

There is no dedicated package in Yocto. Tizen IVI, however, contains the dedicated “festival” library, the dedicated “sphinx” library, and even a dedicated “speech-recognition” daemon, which may however need some modifications.

Proposal : use the festival/sphinx packages from Tizen IVI. Evaluate the speech-recognition daemon of Tizen IVI.

In this chapter, for each package group listed in §5.1[Global gap : Tizen IVI / Yocto 1.7], we try to find a match in GENIVI, Upstream and Tizen IVI.

GUI resource management

The Policy Manager (AGL§4.1.3.1.2) requires the following :

• Weston 1.7, for IVI-Shell : in Yocto 1.8 ;
• Policy manager : Tizen IVI contains Murphy, which fulfills the requirement.

Preinstalled applications

Only a HomeScreen is mandatory (AGL§4.1.3.1.2).

Tizen IVI contains 2 packages fulfilling the requirement : ICO and Modello,

• ICO is native, whereas Modello is HTML5 ;
• Both are not heavily maintained anymore, though.

Proposal : choose one and resume its maintenance.

Screen Sharing

Miracast (AGL§5.1.13.1.2) requires an implementation.

Tizen IVI had WiDi, which fulfills the requirement, but it was not included due to royalty fees issues.

Digital Multimedia Server

DLNA (AGL§5.1.13.1.3) requires the following :

• Yocto 1.7 contains Dleyna 0.4.0, which fulfills the requirement.

Login and security

From AGL§4.1.6.7 : login/password is mandatory, NFC and biometric identification COULD be supported.

Yocto 1.7 contains Neardal, and Tizen IVI contains nfc-manager-neard. Both are needed in order to fulfill the requirement. Adaptation is needed for nfc-manager-neard.

Applications

An Online Store is needed (AGL§3.1.8.3), with support for secure communications.

Local databases and multi-user support are needed for applications.

Sound

A Sound Manager is needed (AGL§4.1.4).

The gaps between Tizen-IVI and Genivi packages as extracted from Genivi mailing list and Yocto repository originate from 3 main motivations: license dependency on GPLV3, specific requirements addressed by Genivi or simplicity of construction.

For most of the packages, it should be relatively simple to make a pragmatic choice of which version or a given package should be used or not. For some others nevertheless due to complex dependencies, this decision might me more political than technical.

Going further and aiming at AGL-1.0 compliance, it looks obvious that even by collecting every packages from Tizen, Genivi and Yocto some functionality would still miss.

In order to move forward: first basic version conflict of identical packages in between Yockto/Genevi/Tizen should be cleared out. Secondly the AGL architecture group and steering comity should address missing functionality and choose technologies they would like to use to address those requirements.

(see Appendix for additional data)