Android™ Automotive SIG
Multi-OS Integration Project
Domain Interaction Projects
Cloud & Connected Services Project
GENIVI Github Repository
GENIVI Code Project Descriptions
GENIVI Yocto IVI Baseline
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.
In order to enhance the user experience and to ease adding new applications to the GDP, the GENIVI Graphics Team has provided a brand new user experience which is being integrated into the GDP RC2. This significant feature enhancement will be highlighted at the upcoming GENIVI All Member Meeting (AMM) and will include a GENIVI-branded GUI and configurable application launcher. The updated GDP containing this new user experience will receive additional testing to gain the stability needed for a full release after the AMM.
GDP RC2 includes the latest bug fixes from meta-ivi along with a variety of other bug fixes and small improvements across the system with more stable ports to the development boards listed below. There is also a port to QEMU for those who want to take a quick look at what GDP base system is today.
Intel Minnowboard MAX
Raspberry Pi2 and 3
Qualcomm Dragonboard 410c
Those with Yocto knowledge can build this second release candidate from scratch from the GDP Master, where Renesas Porter and Silk are also supported. Other links of interest are:
GDP 11 RC2 Feature Page provides details on what is new in this pre-release.
GDP Releases wiki page where you can find information on how to run the available GDP 11 RC2 ports to different boards. This is of interest to those application developers who are not familiar with Yocto.
GDP Master wiki page, with instructions on how to build GDP from scratch with support to a wider range of target boards with Yocto knowledge.
GDP 11 Bug Tracking system for those wishing to provide feedback on this release. The GDP Delivery Team welcomes bug reports.
GDP Roadmap for information on the upcoming GDP 11 release.
The GENIVI Alliance appreciates all member and community efforts testing the GDP 11 RC2 and will soon announce a final release candidate with the new user interface for testing.
I recently pushed Genivi 11 support for the Renesas R-Car Gen 2 boards to github.
The branch is a WIP but actually feels very close to a release candidate.
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:-
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.
See the Genivi 10to be reminded of some functional improvements in the previous release.
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!
GDP RC1 includes ports to QEMU, MinnowBoard MAX (compatible with the new Minowboard Turbot) and Raspberry Pi 2 and 3. This first candidate brings several improvements from the latest stable Yocto release 2.1.1 including:
Download GDP RC1 port for your favorite board or QEMU. Those with Yocto knowledge can build from scratch this first release candidate from GDP Master, where work is currently being done to support Renesas Porter, Silk and Qualcomm Dragonboard 410c boards which will take precedence in the final release. Other links of interest are:
We very much appreciate any and all testing of the GDP 11 RC1 as it helps us create a better development platform for those interested in producing automotive software.
The GENIVI Development Platform Delivery Team is happy to announce the first pre-release of GDP 11, the new version of the platform for automotive Open Source developers.
This beta release represents a major update for most upstream software in GDP compared to the previous release GDP-ivi9. Yocto has been updated from version 1.8 (fido) to the latest stable Yocto release, 2.1 (Krogoth). Qt moved from version 5.4.2 to Qt 5.6.0. Several relevant updates on key automotive components are also included. Some of those come with meta-ivi 11. GDP for the very first time ships a development version of meta-ivi so professionals interested in some of the components that follow GENIVI specifications can test them, helping GENIVI Expert Groups to improve them. GDP also ships some other updated automotive specific components beyond meta-ivi like NAVIT, or tools requested by users. Last but not least, GDP 11 beta includes Fuel Stop Adviser (FSA), a new demo application.
You can download the GDP 11 Beta port for QEMU target only from the GDP Download page. Ports to different target boards will be delivered in the next pre-release. The final GDP 11 release is scheduled for mid September, around the same dates that the new release of meta-ivi 11 is expected, on time for the GENIVI 15th AMM.
GENIVI® is a nonprofit industry alliance committed to driving the broad adoption of specified, open source, In-Vehicle Infotainment (IVI) software. The alliance develops an open standard for aligning automotive and consumer infotainment cycles. Our work results in shortened development cycles, faster time to market, and reduced costs for companies developing IVI software. For more information, check GENIVI website.
During the last few weeks, the GDP project has moved rapidly. Summer is the perfect time to work quietly in bringing new improvements since most of you are on vacation. These are the GDP highlights.
Tomorrow Wednesday August 3rd, GDP 11 beta will be released.
After a couple of weeks of discussion, the GENIVI community took the decision per consensus to skip GDP 10 and go directly for GDP 11, This is a similar situation to that which took place some months ago with GDP-ivi8, which was skipped in favour of GDP-ivi9. So nothing new under the sun. The main reason for this decision has been to open the possibility to provide the latest versions of every GENIVI component shipped in a stable release with ports to several target boards to developers and companies on time for the GENIVI 15th AMM.
The specific timeline for GDP 11 is currently under discussion. Feel free to participate, especially if you are willing to contribute software to GDP or intend to use it for demoing your latest application for example, at the GENIVI 15th AMM in October.
This Beta release will bring the latest stable software shipped by the Yocto project (v2.1) together with the latest GENIVI software components (meta-ivi MIRANDA v0.1). The only delivered target will be QEMU. RC1 will bring ports to a variety of target boards. The GDP Delivery Team believes GDP 11 Beta will be the ideal starting point for automotive developers interested in either testing the latest GENIVI software or developing the next generation of automotive components and applications, using as based GENIVI compliant middleware.
On June 2nd, GDP was presented at the OpenExpoES, in Madrid, Spain. On July 13th, GDP was introduced at the Automotive Linux Summit that took place in parallel with LinuxCon Asia in Tokyo, Japan. On October 12th there will be a talk about GDP, with the title "Open Source For Automotive In The Open Becomes Real: GENIVI Development Platform" at ELCE that takes place in Berlin, DE. Obviously the GDP will also be present in several talks, demos and training sessions at the GENIVI 15th AMM, in Burlingame, CA, US from Oct 18th to 21st.
With the new rolling model, the GDP Delivery Team is able to move faster so lots of updates has landed in GDP Master. Impatient developers, addicted to the latest and greatest software can see now in GDP a solid option to develop Open Source automotive software. meta-ivi 10 and 10.0.1 later, together with Yocto 2.0 and Qt 5.5.1 landed to GDP a few weeks ago although lately those fundamental pieces has been updated to meta-ivi M.0.1, Yocto 2.1 and Qt 5.6.
Updates in the bluetooth stack, wayland-ivi-extension, dlt daemon among many others have already landed to GDP, together with updates in weston, mesa and new software like Fuel Stop Advisor, conman-client or openssh-sftp-server, for instance. Qualcomm Dragonboard 410c is now supported in GDP Master. Due to these major updates and the fact that the Delivery Team is preparing GDP 11 Beta release, ports to other boards might not be fully working. This is a temporary state since right after the coming release, their effort will concentrate on ensuring those ports works.
So stay tuned for the coming release of GDP 11 Beta and test the latest Open Source software for automotive. Those closer to GDP and GENIVI, might prefer to follow GDP Master, but do not fall asleep, GDP is moving faster than a Pokemon hunter.
I have pushed updates to the previous Beta release of Renesas R-Car Gen 2 support for the Genivi 10 Yocto Baseline to github .
In summary there have been the following major changes:-
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.
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.
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.
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".
The kernel config has been changed to accept boot args from u-boot when a combined uImage+dtb kernel image is used.
The update has been tested with Genivi Yocto Baseline 10 and the GDP Master branch tag gdp-10.
The past few weeks the GDP delivery team together with some key contributors, have been working on a not very visible but still important change. The GDP project has created the basis for turning the GDP release based delivery model to a "rolling" one. My colleagues will provide in a coming post the technical details behind this change. I want to provide a higher level view of what is happening and why.
GDP was born as a "demo" project. The main goal was to provide a platform to show the software components for automotive that the different GENIVI Expert Groups were developing. This was done through a delivery model focused on publishing a stable and easy to consume version of the project every few months, a major release.
Strictly speaking, the GDP is a derivative. It is based on poky and uses Yocto tools to "create" the Linux based platform, adding the different components developed by the GENIVI Alliance together with upstream software. For the defined purpose, the release centric model works fine, especially if you concentrate your effort in very specific areas of the software stack with a small number of dependencies on the other areas, and a limited number of contributions and environments where the system should work. During 2016, GDP has grown significantly. We have more software, more contributors, more components and more target boards to take care of. Although the above model has not been not challenged yet, it was just a matter of time. As explained in two previous posts, the GDP is moving from being a Demo to a Development Platform. Changing the mission means changing the goals and the target group, which implies the need to adjust the deliverable to meet the new expectations.
So, right after the 14th AMM, the Delivery Team decided to change the delivery model to better meet the new mission, providing developers the newest possible software with an increasing quality threshold. At the same time, in order to increase the number of contributors, the GDP needs to provide a new solid platform every once in a while. That should be done through a solid release.
The key idea behind a modern delivery release model is to ensure that the transition from one stable release to the next one takes an affordable effort. I will display an example to picture the idea.
Imagine an organization that publishes one release per year. Let's assume that a particular release included 100 patches developed by employees and, during the lifetime of the release (1 year too), another 100 patches were added to the product as bug fixes and updates. At the end of the release lifetime, the product includes 200 patches that define the value the product provides to customers and users.
Either for technical or business reasons, a year later it is time to upgrade. Our organization has to create a new Linux based system with newer upstream code and they have to integrate the patches from the previous release plus the updates and bug fixes developed for the coming release.
After a simplification process done by engineers, the number of patches needed to be integrated in this newer base system is reduced to 150. The organization also wants to add to this new release another 100 patches that represent the new features they have been developing during the last year for this new version. The delivery team now has to integrate 250 patches in the new base system, 150 of them coming from the previous release. One might think that the effort required to do this is 2.5 times the effort invested in the previous release. Maybe you think that the effort is not so high since some of the patches have been developed thinking about the new base system. There are many other considerations like this one that might affect the initial estimation. This example is obviously a simplification.
One of the paths to improve the situation is upstreaming those changes that affect generic components. Some companies also upstream their new features early in their development process, generally looking for wider testing, or after they have been released to customers, to increase adoption and reduce future maintenance effort. This is definitely a must do.
From the delivery perspective, the most popular way to tackle the problem though is reducing the release cycle, so the number of patches to forward-port in each release is smaller. The development time and the maintenance cycles are also smaller. The same applies to the complexity of the forward-porting activities. "Jumping" from one release to the next one is easier to do. Add automation of repetitive tasks to this recipe and you feel you have a win.... for some time.
The journey through the "road to hell" becomes more comfortable, but our organization is still getting burned, even in the case that our customers and ourselves can digest releasing frequently. We all know how expensive and stressful a release might become.
The most suitable option to achieve sustainability while scaling up the amount of software an organization can manage without releasing more often than your market can digest is to change your delivery model. Rolling delivery models are a serious attempt to solve this problem, putting integration as the central element instead of the software itself.
This model is not new. Gentoo has been doing it forever, but it was Arch Linux who implemented it in a way that immediately attracted the attention of thousands of developers. Still it was a model with no hope beyond hardcore Linux developers. openSUSE brought this model to a new level by implementing a process whose output was stable enough for a much wider audience, and compatible with the release of a more stable and a commercial releases. Nowadays there are other interesting examples out there that commercial organizations can learn from.
It is still hard to define but essentially it is a process in which ideally you have one continuous integration (CI) pipeline as the one and only entry point for the software you plan to ship. Releases then become snapshots of all or part of the software already integrated after going through a specific stabilization, deployment and release process.
So ideally, if you release a portfolio, you integrate only once, reducing significantly the costs of having different engineers working on different versions of the same software and forward-porting, among other benefits. A rolling delivery model is then a lot more than a continuous integration chain, although that is the key point. Please have in mind that this is an oversimplification. This description doesn't go into detail on other key aspects like maintenance cycles, how upstreaming affects the process, strategies towards updating the released products, etc.
A transformation process that takes an organization from a release centric model to a rolling one is about doing less and doing it faster, so less people can handle more software with less pain, allowing more people to concentrate in creating value, developing new and better software instead of just shipping it.
Moving from a release centric to a rolling model is hard work. Frequently it is easier to start all over again. Since the GDP is still a relatively small project, we can afford going through the transformation process step by step.
The first stage has been creating that single integration chain and treating GDP-ivi9, our latest release, and those that follow it, as a deliverable of what we call today Master. Ideally, no single patch will be added directly to the release branches. They should come from Master. That way, we reduce (ideally to zero) the effort of forward-porting of patches while putting in the hands of our contributors the latest software on a regular basis.
To do so, we are in the process of adapting our simple processes and CI system to the new model, GDP repository structure, the wiki contents, the task management structures, several key policies, our communication around the project...
The GDP will face a very interesting challenge since this model needs to be proven successful for a derivative. If we are able to move fast enough, it will come the time in which we will need to decide if GDP keeps being a derivative or it becomes upstream, that is, either GDP limits the delivery speed based on the Poky release cycle, or we work upstream with the Yocto project to increase our delivery speed. That is a good problem to have, isn't it?
If (almost) everything goes right, after adding a few needed services in GENIVI's infrastructure and ensuring the updated software is in compliance with selected verification criteria, the same number of people will be able to manage and deliver more software. And once the new processes become more stable, automation will not just increase efficiency, it will boost the project by allowing GENIVI to achieve goals that only big organizations with large delivery teams can do. This is the kind of transformation that takes time to consolidate, but has a huge impact. Based on my experience, I believe that if GENIVI is able to sustain this effort and keep a clear direction the next couple of years, the benefits of moving towards a rolling model will be noticeable even outside the industry.
Some of the main reasons are:
The more important policies that rules the submission and management processes are described in the GDP Management wiki page. The main goal of these policies is to create a system in which it possible to keep a constantly developing master branch, as well as providing a platform (branch) that acts as a stable snapshot of a release and as such is maintained for a given period. The policies will be applied by the maintainers, but it is important that users (whether that be contributors etc) follow the guidelines where possible, as this will ensure that GDP is workable for all parties. If a contributor is aiming to upstream a new package into GDP (directly into meta-genivi-dev or via an external layer) then it is expected to be compatible with the current genivi baseline / yocto baseline component versions available in master. This ensures that the GDP continues to move forward. Generally it is expected that any patch / PR to either repository is expected to pass the go.cd integration pipelines to ensure the system is buildable. go.cd/github has been configured to report the status of the relevant pipelines in the PR GUI.
That said this is only used as an initial check, and still requires standard code review. The CI is not bulletproof, build-failures are assessed to check if the PR was the root-cause and acted upon accordingly. Please note: as it stands GDP due to the nature of being defined essentially by two repositories, has well documented / discussed PR scenarios in which PR's to both repositories have to be tested in the same integration test. There is currently no mechanism in place to test this scenario and as such has to be dealt with manually for now. GDP now makes use of selective git submodules to generate the corresponding yocto layers based on the target being built, including meta-genivi-dev which also follows the master branch policy. The remote head of the repo is set to the master branch, i.e master is the default branch. And tags will still be used for snapshots of releases.
As you can see there is still a long way to go towards having a truly continuous delivery model through a rolling release but some fundamental steps has been taken. Obviously it is still possible to contribute to GDP via patches to email@example.com, as stated in the updated GENIVI Contribution policy.
One of the consequences of adopting this new model is that GDP-ivi9, our latest release, gets into the maintenance cycle until the next major release is published, which is expected within this year. There are currently maintenance branches of genivi-dev-platform & meta-genivi-dev.git. The maintenance branch is the name given to the currently supported 'release' branch of GDP. Once a new release is declared and branched from master, the maintenance title is transferred. Only bug/security fixes or specific backport patches / PR's should be based against this branch. It is expected that a user looking for a 'stable' GDP build (or requiring a certain version of a package) would use the maintenance branch:
The fact that we have now two deliverables instead of one targetting different audiences have an impact in the way our contents are structured. Now there is one central page for each one of them from which GDP Master is their page. Those more interested in a more conservative and easy to consume approach should go to GDP Releases wiki page. The reference page to download images and metadata remains unchanged.and users can get all the information required to either run or download and boot GDP. For those who want to consume the latest and greatest,
As usual with key changes, there is still some work to be done in order to update contents in several pages, check links, titles, references to Master, update diagrams, etc. Not all this work is completed but most of the relevant updates are done by now. Feel free to point us to potential improvements.
Since Master is the central integration point and it is a continuous effort, we have re-structured the GDP Epics to reflect that most of the work is done now in Master. We have extended the usage of the JIRA capabilities related with Releases (FixedVersion), simplified the interfaces to create/update tasks, improve the integration between GitHub and JIRA/Confluence and other actions that will make our everyday work a little more efficient and easy to follow.
The main GDP Delivery Epics are now:
In summary, GDP has adapted the traditional GENIVI delivery model to a more flexible and modern one, executing actions at different level as consequence of the changes introduced
GDP Delivery Team
Renesas R-Car M2 Porter and E2 Silk boards are now available from two new distributors Avnet and Marutsu. Avnet are shipping worldwide.
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 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
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.
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.
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.
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.
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.
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.
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.
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.
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 .
I have also contributed a patch set for GDP on Genivi 9 to the GDP ML  which should find its way into the GDP project soon.
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 .
The Click Through Licensed Gfx and MM Package has been updated to v20151228. Please update.
The Qt support was verified using meta-qt5.
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  have been written to use those same components and so support an easy move to a later Weston if required.
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.
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.
Build Configuration for the test:
meta-yocto-bsp = "(detachedfromeb4a134):eb4a134a60e3ac26a48379675ad6346a44010339"
meta-ivi-bsp = "(detachedfrombfd95c5):bfd95c5021885ed61b58a33087a4ee8e3d2f32ad"
meta-ruby = "(detachedfrom5b0305d):5b0305d9efa4b5692cd942586fb7aa92dba42d59"
meta-qt5 = "(detachedfrom90919b9):90919b9d86988e7da01fa2c0a07246b5b5600a5d"
meta-genivi-demo = "(detachedfrom6c13a96):6c13a96ba719c657bd69f7c0212cd224def036c8"
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.