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.
- 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.
- Somewhere near a new major release, a numbered release branch (e.g. 14.0) is created from master, and the new branch goes into stabilization/release phase.
- Major numbers are stepped up every new release. The release schedule is driven by a time plan. Use semantic versioning for minor and patch numbers.
- GENIVI-specific release tags, such as "M-0.2" for the second baseline prerelease for the "M" platform may also be added.
- After a versioned release, the release branch remains for maintenance and updates.
- The project 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.
- 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).
- 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.
- 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.
URI: git://git.yoctoproject.org/poky
branch: pyro revision: 3f97cd3514f3e6025788ab7d6eec586fb7ac542f
URI: git://git.openembedded.org/meta-openembedded
layer: meta-oe branch: pyro revision: 5e82995148a2844c6f483ae5ddd1438d87ea9fb7
URI: git://git.yoctoproject.org/meta-gplv2
branch: pyro revision: 07e5dd2136a2a7cc069ad8c70bb422fa9d5b14f0
Using the above git sha's and the master meta-ivi branch, bitbaking orion-image is known to work (the orion-image build should be aligned with GENIVI 13.0).
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 README.md 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 README.md 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.
We do smoke test the builds of the three machines that we currently support:
- QEMU (ARMv7) - emulated machine: vexpressa9
- QEMU (IA-32) - emulated machine: qemux86
- QEMU (x86-64) - emulated machine: qemux86-64
- QEMU (ARM64) - emulated machine: qemuarm64
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.