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
I blogged back in September of last year about R-Car Gen 2 Beta support for Genivi 11.
That support has been stable for several months. I have therefore merged the existing WIP (work in process) branch stevel/genivi-11-wip into a new product branch genivi-11-bsp-1.10.0. This new branch will be used for any future maintenance and has been set as the new default branch in github .
There are no other changes, i.e. no new commit to either branch.
The full release of GDP 11 is now available and can be found here. Since the October AMM, GDP 11 has undergone extensive testing to confirm stability and is proven on additional hardware targets. Like the previous release candidate, GDP 11 includes a GENIVI-branded GUI and configurable application launcher, an enriched Software Development Environment (including SDK) and increased vehicle connectivity with Remote Vehicle Interaction Core and SOTA Client software.
GDP 11 highlights include:
Those with Yocto knowledge can build this release from scratch using the GDP 11 build instructions. Other links of interest are:
The GENIVI community welcomes all member and open source community efforts to further enhance the GDP making it a fully featured and continuously enhanced development platform product. Additionally, GENIVI appreciates assistance in the areas of testing, bug reporting, patching and new feature requesting to advance GDP development (technical discussions occurring on genivi-projects email list and on Jira trackers).
Release notes courtesy of Traci Renner.
Delivered and enhanced by the GENIVI community, the GENIVI Development Platform (GDP) has progressed significantly moving from a demonstrator to a true development platform with the new GDP 11 Release Candidate 3 (RC3) . Like the previous release candidate, GDP 11 RC2, the GDP 11 RC3 includes a number of new features including an enhanced user experience with a GENIVI-branded GUI and configurable application launcher. Also included in GDP 11 RC3 is an enriched Software Development Environment (including SDE) and increased vehicle connectivity with Remote Vehicle Interaction Core and SOTA Client software. All of these new features will be highlighted at the October All Member Meeting (AMM). Additionally, the GDP 11 RC3 containing this new user experience will receive further testing to gain the stability needed for a full release after the AMM.
Easier to install, build and use
Successful deployment on the low-cost Raspberry Pi boards
Developed in an open and collaborative environment, following the best practices of any reputed FOSS community
Combines the new UI and application launcher with the latest stable Open Source automotive software components and the latest stable generic Linux based software provided by the Yocto project
Consistent with v. 11 of the GENIVI Platform Compliance Specification and its related Baseline
GENIVI has provided two release candidates for prospective adopters who may have different goals. GDP 11 RC2 gives adopters a more stable experience given the weeks of testing on multiple hardware boards, though without the new UI and application launcher. GDP 11 RC3 gives adopters the absolute latest set of features including the new UI and application launcher, though the stability of this candidate is still being proven.
Those with Yocto knowledge can build this release candidate from scratch from the GDP Master, where work is currently being done to support multiple Intel and ARM-based development boards. Other links of interest are:
GDP 11 RC3 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, RC3 ports to different boards and the new SDE . 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 11 Roadmap for information on the upcoming GDP 11 release.
The GENIVI community welcomes all member and open source community efforts to further enhance the GDP making it a fully featured and continuously enhanced development platform product. Additionally, GENIVI appreciates assistance in the areas of testing, bug reporting and patching to advance GDP development.
GENIVI Marketing Team
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.