You may have noticed that the GDP team recently made the first release of the Genivi Demo Platform (GDP) on Genivi 9 for QEMU. I am happy to announce I have just pushed support for it on the Renesas R-Car M2 Porter board to the mailing list and it should appear in the GDP git repository soon.

This first Beta release will help members prepare their Hands On Training on the Porter board for the upcoming Paris AMM. Other R-Car Gen 2 boards will follow soon. 

Developer summary

I have pushed a Beta release of Renesas R-Car Gen 2 support for GDP on Genivi 9 (meta-ivi 9 and YP 1.8)  to github [1].

I have also contributed a patch set  for GDP on Genivi 9 to the GDP ML [2] which should find its way into the GDP project soon.

[1] https://github.com/slawr/meta-renesas/tree/experimental-genivi-9-bsp-1.10.0
[2] http://lists.genivi.org/pipermail/genivi-projects/2016-March/001584.html

Developer Notes

R-Car Gen 2 Yocto BSP (YBSP) v1.10.0

As well as rebasing on meta-ivi 9, I have taken the opportunity to migrate to the latest Yocto BSP v1.10.0 at the same time.
The principal functional change is that the kernel recipe now supports kernel CONFIG fragments in .cfg files. For example, the CAN config [3].

[3] https://github.com/slawr/meta-renesas/blob/experimental-genivi-9-bsp-1.10.0/meta-rcar-gen2/recipes-kernel/linux/linux-renesas/can.cfg

Updated Click Through Gfx and MM Package

The Click Through Licensed Gfx and MM Package has been updated to v20151228. Please update.

Major changes:

•  - Bug fix in the Wayland WSEGL library
•  - Added support for Weston v.1.8.0, 1.9.0
•  - Added support for eglfs plugin in Qt5.5

 The Qt support was verified using meta-qt5.

Weston >= 1.6.0

Meta-ivi 9 supports the Weston 1.6.0 shipped in Poky meta and so the YBSP provides recipes for the same.

The gfx components have been tested with Weston 1.8.0 and 1.9.0. The YBSP Weston recipes [5] have been written to use those same components and so support an easy move to a later Weston if required.
[5] https://github.com/slawr/meta-renesas/tree/experimental-genivi-9-bsp-1.10.0/meta-rcar-gen2/recipes-graphics/wayland

A next step will be to confirm the GDP for Weston 1.9.0 that is being developed by the GDP Team works on Porter. That will also inform how best to carry Weston 1.9.0 recipes in the YBSP. For now it should be sufficient to simply rename the 1.6.0 filenames of the bbappends to 1.9.0.

GDP on Genivi 9 (meta-ivi 9) and YP 1.8

Sanity testing a new build (re-used downloads folder) GDP runs fine on M2 Porter. The PoCs all ran ok, with the exception of the Audio Manager PoC which draws but reports a Pulse Audio/ALSA issue.

Known issues:

1. Starting the Audio Manager PoC causes an issue seemingly because of a pulseaudio problem. FIXED. Problem found in GDP.
2. Some build log warnings.

Build Configuration for the test:

meta              
meta-yocto        
meta-yocto-bsp    = "(detachedfromeb4a134):eb4a134a60e3ac26a48379675ad6346a44010339"
meta-ivi          
meta-ivi-bsp      = "(detachedfrombfd95c5):bfd95c5021885ed61b58a33087a4ee8e3d2f32ad"
meta-oe           
meta-multimedia   
meta-filesystems  
meta-ruby         = "(detachedfrom5b0305d):5b0305d9efa4b5692cd942586fb7aa92dba42d59"
meta-qt5          = "(detachedfrom90919b9):90919b9d86988e7da01fa2c0a07246b5b5600a5d"
meta-genivi-demo  = "(detachedfrom6c13a96):6c13a96ba719c657bd69f7c0212cd224def036c8"
meta-renesas      
meta-rcar-gen2    = "experimental-genivi-9-bsp-1.10.0:b29891865a81380eab608fa570a1f43eb7aaf84c"

GENIVI's mission is well-known; it's about bringing a thriving ecosystem of Open Source software to the automotive industry. This is often easier said than done. While there are no shortage of GENIVI members with considerable expertise in automotive software development, the work of getting production quality specifications and standards into the broader marketplace of the Open Source community is sometimes not as straight-forward as designing a protocol or component. Often there is more heavy lifting involved, namely in building consensus on the best technical approach. GENIVI continues its design work and even provides complete system integrations for demonstration purposes in order to align the competing interests found in Open Source communities. Those competing interests are important competitive ideas that allow the community to thrive, and GENIVI wants to encourage that diversity while at the same time build the shared code base that innovation sits upon. That work requires considerable collaboration around software implementation since the result everyone wants is awesome, working software.  

Here’s a recent example of GENIVI’s collaborative work from the folks who work on Layer Management. The problem the team identified is that IVI displays require layering to support simple but important functions like pop-up management which can inform a driver of both critical and actionable information. GENIVI members recognized that this functionality was essential in an IVI context but was not developed and available in the Open Source community. After working with the Wayland project to create a layer management implementation that fits with the Wayland protocol, the IVI Layer Management Project was able to get their IVI shell patches accepted into the QtWayland library.

The result is that GENIVI members delivered some very useful functionality that is broadly available and significantly impacting in-car software. The functionality called IVI Shell provides a central controller to the HMI to raise and lower different layers in the various screens in the cockpit. This central controller is also designed to be used with the cluster for example, future-proofing the implementation. After the IVI layer management synchronization was done upstream with Wayland, work began on a somewhat arduous trek to get IVI shell into Qt. The target chosen was QtWayland logically enough because with that tool you can use Qt as your compositor and have clients and controllers speak the IVI dialect of the Wayland protocol. 

All this is to say that the requirements and specifications from GENIVI members are having an impact on how large community run projects are being built, which is the kind of meaningful impact GENIVI was meant to have. Many GENIVI members deserve credit here, not least BMW, Intel, ADIT, TQC and Codethink, all of which played key roles in supporting the software developed to the GENIVI specifications. The consequence of this patient collaboration is that while the wider community is enriched, GENIVI members now have an automotive standard to use when they design their next cockpit. It comes to them from an automotive supplier, built for production quality, and allows HMI designers to focus on the differentiating part of their work as opposed to merely recreating boilerplate. This is a process that holds significant value, it allows code reuse across the industry and that introduces a network effect improving the quality of the software. While there is effort required to collaborate with upstream, the return on investment is significant as the Layer Manager process illustrates, both for the alliance and for GENIVI members. 

Engaging the Open Source community and the many large enterprises that now make up its competing interests can be challenging. I think the Layer Management example is a proof point that GENIVI can help automotive software developers with that challenge. The alliance is much more than just the opportunity to gather and showcase the latest IVI demos, it’s a place where one can acquire know-how on engaging the very large Open Source software community, and deliver your own innovations to the market. I'd urge you to take a second look at some of the opportunities to engage in the active projects in GENIVI and harness the very real benefits the alliance has to offer. We welcome your participation through our public tooling, email lists and hosted code projects.