A useful tool when developing an Automotive Infotainment is a screen to view the User Interface. Recently work has been done to support the official Raspberry Pi 2 7" touch screen, as seen here: raspberry-pi-7-touchscreen-display.

If you build automotive infotainment systems, you know that the integration of hardware and software is a key differentiation. In building the GDP we don't have the resources for custom designed hardware so instead we use COTS or common off the shelf technologies. In fact the GDP supports a number of peripherals almost entirely by contributors.

The RPi touchscreen has required a bit of work to get it to work with the GDP, namely drivers in the RPi. Leon Anavi as well as GDP maintainers worked to bring in the needed software and configuration which inevitably led to upstream. Once an open source driver was brought into Linux mainline, the next step has been ensuring that the Graphical tools used by GENIVI, namely Wayland and the Wayland IVI Extension, work on the screen.

While continued discussion is happening on using the screen with GDP 11, it should be ready for everyday use with both the Raspberry Pi 2 and 3. Use the links I've provided to follow along with the collaboration with many parts of our community as we continue to support widely available and popular hardware running the GDP.

Developer summary

I recently pushed Genivi 11 support for the Renesas R-Car Gen 2 boards to github.

URL: https://github.com/slawr/meta-renesas.git

branch: genivi-11-wip

The branch is a WIP but actually feels very close to a release candidate.

Developer Notes

The support is based on the same Yocto BSP v1.10 release used for Genivi 10 and there are no changes to the BSP components.
Changes were limited to adoptions to the krogoth (YP 2.1) branches used by the Genivi Yocto Baseline and of course meta-ivi 11.
Functionally the Poky meta implementation of libdrm is now used.

In summary there have been the following major changes:-

• Support gtk+3 v3.18.8 used in YP 2.1
• Support systemd v299 used in YP 2.1
• Support gst 1.6.x used in YP 2.1 when h/w acceleration is disabled.
• Support mesa 11.x used in YP 2.1. Update configuration (disable libgbm) to fix do_populate_sysroot() error
• Fix omx-user-module QA issue in do_populate_sysroot() related to .la files
• No longer use Renesas libdrm fork
• Fix build error related to linux-libc-headers
• Drop ncurses bbappend as functionality now upstream
• Drop unused gcc 4.8 bbappend

For those who like a graphical diff compared to Genivi 10 you can find a Github compare here.

The following sections provide some more detail including a migration guide.

General information about building Genivi 11 Miranda for the Renesas R-Car SoCs, including build instructions for the Genivi Yocto Baseline and links to GDP can be found in the Renesas Genivi 11 page.

Migration Guide / Behavior changes

• No changes to the BSP components.

See the Genivi 10 Migration Guide to be reminded of some functional improvements in the previous release.

Testing

The update has been successfully tested with Genivi Yocto Baseline 11 M-02 and the GDP Master RC-1 release for Genivi 11.

Pull request #44 is pending for GDP-11 RC-1 to align the GDP Master branch with this release. The GDP Maintainers tell me they are about to merge it.

Earlier in July GENIVI received configuration for the GENIVI Development platform to run on another popular development board. This time it was Qualcomm’s Dragon Board. This board uses the Qualcomm Snapdragon 400 processor and includes things like bluetooth and GPS and seems quite well suited to running automotive software. I'm including a screen shot below from GitHub showing how Changhyeok Bae and Tom Pollard spun the new board up. Since GENIVI uses build-from-source build tools, namely Yocto and Baserock, we're able quickly port GDP to new hardware as long as there is a fairly recent kernel available for the hardware. 

We look forward to more silicon joining the stable and a warm welcome to the Dragon board!

Developer summary

I have pushed updates to the previous Beta release of Renesas R-Car Gen 2 support for the Genivi 10 Yocto Baseline to github [1].

They have been pushed to the new product branch "genivi-10-bsp-1.10.0". This replaces the previous working branch "stevel/genivi-10" which is now deprecated and will be later deleted.

[1] https://github.com/slawr/meta-renesas/tree/genivi-10-bsp-1.10.0

Developer Notes

In summary there have been the following major changes:-

• Fix "full path to dts" kernel bitbake build warning
• Fix "license listed foo was not in the licenses collected" bitbake build warning
• Various readme updates or improvements
• Added sample local.conf and bblayers.conf
• Kernel config changed to receive bootargs for u-boot when combined uImage+dtb image used
  
  

For those who like a graphical diff you can find a Github compare here.

The following sections explain some of these in more detail including a migration guide.

Yocto Bitbake Warnings

The updates address two bitbake warnings. The first addresses a malformed recipe variable that resulted in bitbake raising a license warning. The other addresses a bitbake kernel build warning related to dbs/dtb files.

Migration Guide / Behavior changes

U-boot

The Yocto board machine files, e.g. porter.conf, now default to the setup for Wayland/Weston. This means you no longer need to set this explicitly yourself in your local.conf.

Sample local.conf and bblayers.conf

The Yocto BSP supports multiple boards so it is impossible to add a local.conf.sample and bblayers.conf.sample that covers all boards. Examples for the different boards are available upstream, but I can see the value of having a sample within the Yocto BSP itself.

The commit adds a bblayers.conf.sample that should be applicable for all Gen 2 boards. The local.conf.sample is for the Porter board. For other boards change the MACHINE variable and in addition for H2 SoC based boards such as Lager change the MACHINE_FEATURES_append variable to be "rgx" rather than "sgx".

Kernel

The kernel config has been changed to accept boot args from u-boot when a combined uImage+dtb kernel image is used.

Testing

The update has been tested with Genivi Yocto Baseline 10 and the GDP Master branch tag gdp-10.

Renesas R-Car M2 Porter and E2 Silk boards are now available from two new distributors Avnet and Marutsu. Avnet are shipping worldwide.

Details of where to buy boards can be found here for Porter boards and here for Silk.

This post is a June update about the git repo migration, not a Star Wars spin-off. I apologize for the clickbait but I need your attention for an update on the migration of git repos in GENIVI. I want to communicate the timeline that is in place for the git repos hosted on git.projects.genivi.org. The physical migration of repos was done as a set of clones on deadline on the 24th. The next step is to ensure that those cloned repos are in a location suitable for URLs used in build tools and scripts to "just work". That will mean that we have both proper repo configuration and DNS set up. Work is still ongoing in this department and myself along with GENIVI IT will keep you updated as we go forward. 

Even before we have the URLs complete we're going to start making some repos from git.projects.genivi.org read-only. This is because we want to make sure we don't lose any commits or patches. With git being a distributed version control tool, this is less of a worry as long as the code exists somewhere, but it might be disruptive if something falls between the cracks as it were. 

Ideally, if you have a repo on git.projects.genivi.org, you've moved it already to GitHub, or are about to. We can of course help with that and recognize that it may be inconvenient for you to do this so please send an email to me and I'm happy to set things up. We have 38 committers now on GitHub with 32 active repositories.

This blog post is designed as a central place information on the GENIVI repo transition from git.projects.genivi.org to GENIVI's GitHub account and to a new GENIVI-hosted git mirror and archive. 

This post is for the "how" of the migration, not the "why". You can also view these email threads for reference and background: http://lists.genivi.org/pipermail/genivi-projects/2016-April/002039.html and http://lists.genivi.org/pipermail/genivi-projects/2016-May/002216.html 

What is the status of the transition?

What happens to the git.projects.genivi.org repos? 

These repos are mirrored on a new server in JLR's Portland facility. The repos will be switched to "read only" so that we do not get updates to separate git repos. New development should happen at GitHub, the old repos remain for two years to provide a link for older versions of the GENIVI Compliance Specification and for convenience for automated software builds. As we turn the git repos from write to read only, we'll also be deactivating the public ssh keys associated with the accounts on the repositories. This is for security purposes. 

Is it necessary to change Yocto recipes?

No, it shouldn't be. The point of making the GENIVI mirror use the same URLs was to preserve access for Yocto layers and recipes, as well as other tooling like baserock. If you want the latest and greatest GENIVI code, it might be best to look at GENIVI's GitHub account.

How do we mark GitHub projects as being part of GENIVI?

When repos are put onto GENIVI's GitHub account they automatically become part of the GENIVI GitHub space. This is reflected in the URL for example, as well as other places: https://github.com/GENIVI/capic-poc Everything under https://github.com/GENIVI/ is part of GENIVI. GENIVI has an organizational account at GitHub and is responsible for the terms of service agreement with GitHub.

Will everything work the same as before the migration?

No. Pushing to git repos, that is to say developing new code, will be done at GitHub. There may be a way for GENIVI to set up push access but this is only for certain situations where GitHub's terms and conditions are unacceptable.

Is there a common GENIVI "look & feel" for GitHub projects?

 No, we inherit GitHub's look and feel. There is a substantial API however so we may be able to create our own look and feel if wanted.

Is it possible to transfer a GitHub account to a new maintainer?

Yes. I wouldn't conflate the terms "account" and "maintainer" though since GitHub uses those terms differently than we do. We can create numerous accounts and transfer maintainership between them as well as use team based access control, in fact we're doing that now.

How should a GitHub account be handled, if the project has more than one maintainer? Is it allowed to have more than one maintainer?

Yes, you can have more than one maintainer. The best practice is likely through team maintainership. By adding multiple maintainers to a team you can easily have more than one maintainer. You can also limit each team member to a specific set of functionality, like read-only, or write and push, and even able to create new team repos. Teams can be created around any repo, or set of repos, and can contain one or more GitHub accounts.

What else should we do?

It might be nice if you made your membership in the GENIVI organization 'public' – it is by default private when you are added as a member in the GENIVI Organization in GitHub.  Making the association public makes your belonging to GENIVI visible on your personal GitHub page.  Also, adding two factor authentication is a good idea for protecting both your account and GENIVI. Add an avatar as well to easily identify contributors.

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.