Skip to content
This repository has been archived by the owner on Nov 2, 2021. It is now read-only.


Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time

meta-ivi, the Yocto layer for In-Vehicle Infotainment

This layer's purpose is to add In-Vehicle Infotainment (IVI) support when used with Poky. The goal is to make the Yocto Project reference system Poky GENIVI compliant.

Branch Policy

  • New development is done on master branch and most new change requests (PRs) should be proposed as changes to master, unless you know they are applicable to a particular release only.
  • In general, prefer a linear commit history (rebase and cherry-pick), applying merge commits only where absolutely necessary to sort out a complex merge situation (which we should rarely have).
  • The maintainer shall ensure that relevant patches are cherry-picked to every branch where they apply. I.e. patches should be back-ported at minimum to the Support Window versions, as defined below.
  • Meta-ivi uses semantic versioning.
  • The release schedule is driven by a time plan.
  • The GENIVI Compliance Specification is released annually, while meta-ivi is released twice a year. Major numbers follow the compliance specification. E.g. We will create 14.x-rocko branch together with the specification 14.0.0 and 14.x-sumo half way to 15.0.0.
  • Meta-ivi updates regularly to follow Yocto/Poky releases.
  • Somewhere near a new major release of the specification, a numbered release branch (e.g. 14.x-rocko and 14.x-sumo) is created from master, and the new branch goes into stabilization/release phase.
  • In the middle between the specification version 14.0 and 15.0 a numbered branch is created for the 14.x-sumo meta-ivi release.
  • After a versioned release, the release branch remains for maintenance and updates.

Tag Policy

  • Meta-ivi creates tags, in accordance with semver. Major numbers follow the GENIVI Compliance Specification. Examples: 14.0.0, 14.0.1, 14.1.0
  • Releases are created from the respective working branch.
  • GitHub releases are also created.
  • When layer upgrades are done, version numbers will be as follows:
  • The versions used on 14.x-rocko will start at 14.0.0.
  • The versions used on 14.x-sumo will start on 14.50.0 to keep the major version numbers in sync.
  • Note: Updates to the 14.0.0 release would then become 14.0.1 and/or 14.1.0, which can be released after 14.50.0.
  • Tags of the type P-0.1, P-0.2 etc, are internal tags used for some prereleases.

Support Window (Bugfixes, improvements)

  • Because of available resources, and often low engagement from those companies that have settled on a version and gone into a production project, support is given for only the most recently released version, and one version before it.

Support Window (Security)

  • If critical security fixes are identified, the maintainer should apply them (if applicable) to the most recently released version and two versions before it.

Note however that there is currently no quantified or documented commitment to tracking CVEs, nor any guarantee to apply all possible security fixes. While it is of course tracked to the best of the maintainer's ability, the project is dependent on community input. All the responsibility remains on the adopting companies to secure their final products.


The meta-ivi project welcomes contributions. You can contribute code, submit patches, report bugs, answer questions on our mailing lists and review and edit our documentation and much more. Wiki page. Mailing list report Bugs.

Please see the MAINTAINERS file for information on contacting the maintainers of this layer, as well as instructions for submitting patches.

Subscribe to the mailing list here. View or Report bugs. Read the wiki.

For information about the Yocto Project, see the Yocto Project website.

For information about the Yocto GENIVI Baseline, see the Yocto GENIVI Baseline wiki.

Layer Dependencies

URI: git://

branch: thud revision: 50f33d3bfebcbfb1538d932fb487cfd789872026

URI: git://

layer: meta-oe branch: thud revision: 4cd3a39f22a2712bfa8fc657d09fe2c7765a4005

URI: git://

branch: thud revision: aabc30f3bd03f97326fb8596910b94639fea7575

Using the above git SHAs and the master meta-ivi branch, bitbaking meta-ivi-image is known to work.

For creating a specific GENIVI compliant image version, please make sure you git checkout the related meta-ivi branch and follow the build instructions located in the file of that branch. So for example, to build an image that should be GENIVI 9.0 compliant, checkout the meta-ivi 9.0 branch, and follow the part of that branch. As does the GENIVI Alliance we only support the current and the previous version. Any version older than that is not supported any more, and therefore may not build or run.

Supported Machines

We do smoke test the builds of the three supported machines:

  • QEMU (IA-32) - emulated machine: qemux86
  • QEMU (x86-64) - emulated machine: qemux86-64
  • QEMU (ARM64) - emulated machine: qemuarm64

Adaptation and testing with other hardware BSPs is typically done by other community projects like the GENIVI Development Platform, and by product companies.

Please check on our wiki regarding any community supported machines. For example there Renesas provides a public Board Support Package (BSP) available for use with meta-ivi.


THIS REPOSITORY IS ARCHIVED i.e. please fork the project if you wish to develop it further




Unknown, MIT licenses found

Licenses found






No packages published