The theme of ELCE was centered around the 20th anniversary of Linux.  In attendance were community personalities including Linus Torvalds, Dirk Hohndel, Theodore Ts’o, Alan Cox, etc. etc.  To list all the kernel developers present would take an article unto itself.  Needless to say, the presence of so many Linux “celebrities” added a certain buzz to the conference.  The opening keynote kernel panel consisted of Linus, Alan Cox, Thomas Gleixner, and Paul McKenney being subjected to Questions from both the moderator, Lennart Poettering and audience members.  What I assumed would be a discussion of present technical issues in kernel development and glimpses into the future turned into a discussion about the inevitable ageing of the core kernel development team.  Although this wasn’t the content I was hoping for, it is a somewhat contentious subject within the kernel development community.  My impression from the answers given by Linus and the like is that it’s not really an issue at all.  Yes, core developers are ageing, but there are many new, young developers participating as well.  The general idea that a young developer can simply jump into kernel development and contribute significantly is waning as the kernel grows in complexity.  Not to say that the latter is impossible, it’s just become less common.  However, the young kernel hackers are climbing the kernel development learning curve, it’s just that the curve has increased.

Another interesting amount of content centered around the history of Linux, and in particular the experiences of kernel developers in the early days.  Dirk Hohndel presented a Day 2 keynote describing his experiences in those early days.  Dirk stressed that in those days there was no grand plan of world domination, no prescient ideas about where Linux could go, but rather a series of challenging, fun technical problems that needed to be solved.  He, Linus and the other early contributors were having fun.  Each day consisted of trying to see what problem could be solved that day, like getting a new piece of hardware to come up, or adding a new tool.  Community was always the key to the success of Linux.

Most of the big players in the Embedded Linux space were present at ELCE.  The Yocto Project, Linaro, RedHat, Intel, Texas Instruments, Sony, etc. etc. indicating that a lot of Embedded Linux development continues to be sponsored by these organizations.  MontaVista played a role as well, with developer Klaas van Gend hosting the closing comments and games.  Klaas bravely opened a web server to gather game answers during the closing session which was playfully hacked by a member of the crowd.  But Klaas was not deterred, restored his server and soldiered on with a very entertaining closing session.

The 2011 Embedded Linux Conference Europe was a qualified success for me, even though I was not able to attend many talks due to illness.  The Embedded Linux community presence was strong, demonstrating its health and the continued growth of Embedded Linux development everywhere.
Linux Foundation will hold the next Embedded Linux Conference in Redwood Shores, California from February 15th-17th, 2012.

* Presentation from ELCE can be found on the elinux.org wiki.

* The conference schedule can be found on the Linux Foundation event page.

Can you describe the code contribution made to the Yocto Project?

MontaVista has made two main code contributions to the Yocto project.  The first deals with remote layering in BitBake and the second with layer management. Note that the terms collections and layers can be used interchangeably. Collections and layers are conceptually identical, but layers are implemented at the BitBake level, and collections are implemented at the metadata level.

* Remote layering

Back when MontaVista started working with BitBake we implemented the amend.bblass and collections.inc features to simplify how we run our business and our development. Both features were pushed back into what is now OpenEmbedded Classic. Both features were powerful and simple. The primary problem with both was that they existed primarily in the content, thus there was always a bit of fragility in how it all worked together.

In the intervening couple of years, the OpenEmbedded community has mostly moved those features into BitBake proper. During that same time MontaVista enhanced the collections feature, such that a collection could be a proper URI, rather then just a directory path. This functionality did not make it back into the upstream community code.  MontaVista’s submission to the Yocto/BitBake code stream proposed to add the URI feature into the BitBake layers implementation of collections.

The exact patch that was submitted was not accepted, but it was a good starting point to the discussion about supporting remote layers. Yocto Project members Paul Eggleton, Richard Purdie and I have had ongoing discussions about the various pieces of remote layers and how they come together. I think the final implementation of remote layering support will work for everyone involved. Paul has done a superb job at bring all of the issues together and putting something out that we can all work with as a community.

* Layer management

One of the key items that has been lacking in the community code base since collections were first pushed to OpenEmbedded, was an effective manner to manage which collections are in a given build project. However, it was never a big burning issue, because OpenEmbedded classic is one giant repository, so there wasn’t much to manage, even if you were using collections. What you were adding as a secondary collection tended to be much smaller and most likely non-overlapping.

When MontaVista developed the MVL6 product based on OpenEmbedded, we decided to take a much more modular approach to how MontaVista provided content to our customers. Once we got down to breaking up content into a core set of functionally coherent collections, MontaVista needed a set of tools to handle their management for people who know very little about all the inner-workings of BitBake and OpenEmbedded content. Our first iteration of those management tools were very MontaVista-centric, over time we have made our content management tools generic enough that they could be useful to a non-MontaVista customer/user.

Fast forward to the beginning of the Yocto Project. From its inception, Yocto, whether intentionally or otherwise, has adopted the model MontaVista provides to our customers. From breaking up the gigantic collection that is OpenEmbedded Classic into OpenEmbedded-core and sublayers like meta-oe, meta-intel, etc. and focusing on a layered approach to development.  Naturally, MontaVista saw places where we had already made progress and had experience such that we could provide code and guidance given that we had previously encountered similar or the same issues.

One of the major gaps was/is layer management. MontaVista provided an unbranded version of our content management tools with some tweeks to work with layers, rather the collections, as a means to provide a good foundation and starting point for the final community implementation.

* Why

There are a number of reasons why MontaVista contributed code to the community project. The primary one is that MontaVista wants to be a good member of the community and for various reasons we have not been able to be as good as we desired to be. Yocto is moving the community in a new direction and is supplying the work force to do it. Since MontaVista has been using the Yocto model long before Yocto existed, we had a stable of technologies and experiences that would be especially useful in the overall new direction. One of the primary ideas behind Yocto was to reduce the number of inventions and reinventions of the same technologies. The delivery of remote layering and layer management works in both those regards. From a purely technical standpoint, the contribution seemed obvious.

Given that the Yocto Project is open, can the contributed code be found in the Yocto codebase now?

Yocto itself has a limited code base. Most of the “Yocto” code has been going into the community repositories(BitBake, OpenEmbedded-core). The remote layer handling code is still on a development branch, I believe, and not in the mainline. However, our final marks on that code will be inspirational and collaborative, rather then “we wrote these lines of code”. I am not sure a preliminary version of the yocto layer management tools have been released, so I am not entirely sure about that one.

Will MontaVista be actively maintaining this code within the Yocto Project going forward, or is the hope that the community will dive in?

MontaVista’s involvement for those components was more of a here is how we did it, it would be a good starting point, but ultimately what we gave Yocto will not be the final results. Paul is the primary point of contact for those bits. More then anything it was a discussion about making sure specific usage models were addressed so we could be more closely connected to the community in the future.

For additional reading, please see Jeremy Puhlman – Developer Spotlight.

On August 2^nd, we announced the launch of the GENIVI Member Compliance Program. This program is a critically important milestone for the GENIVI Alliance and is the result of over 2 years of hard work to define a detailed set of technical requirements. These requirements form the basis of a Compliance Specification with well-defined Linux-based OS, middleware and frameworks for sound, graphics, video, Internet connectivity, Bluetooth, media management, location-based services, and much more.

One of the goals of the Compliance Program is to provide well-defined requirements while at the same time allowing differentiation in meeting those requirements. This will result in a thriving GENIVI ecosystem built around these standards, while allowing flexibility for differentiation and value-added features. As an indication of this, upon the launch of the program, GENIVI already announced four GENIVI compliant Linux distributions, including the MontaVista Automotive Technology Platform.  Please be sure to have a look at the press release and the GENIVI Compliance web page.

Now that GENIVI Compliance is well defined, we will start to see product RFPs and RFQs, from automotive OEMs and Tier-1 companies, that will require GENIVI compliance. Why is this important? By defining standards, utilizing open platforms, and by leveraging Linux and open source code, the goal is that this will result in a significant amount of reuse, lower costs and accelerate time-to-market. It will also accelerate the pace of innovation by providing well-defined open frameworks that 3^rd party ISVs can depend on for their product development. This approach has been very successful in other industries, and we expect it to be very successful within GENIVI.

For me, the launch of this GENIVI Compliance Program is more than just the creation of a specification. It is GENIVI finding its legitimate purpose. It is GENIVI hitting its stride. It is saying to the world that this is the place for future IVI innovation and standards. It is the answer to those questions I mentioned, and it will silence any potential critics. It is saying to the world that GENIVI is here, and it is here to stay.

We have big plans to improve and add new requirements to future versions of the specification. Stay tuned for future announcements.

Dan Cauchy’s Bio: http://www.mvista.com/team_cauchy.php

To begin, nothing within the Meld SDK is proprietary. While an SDK is assembled from an existing MVL Market Specific Distribution (MSD), the toolchain and build environment are open source. We can talk more about tools in a minute, let’s back to content.

Another key difference between a MVL MSD purchased from MontaVista, and a Meld SDK is that MontaVista actively supports, updates, and most importantly tests MVL MSDs. In contrast, Meld SDKs are supported through the Meld community Discussion forums. Meld members help other members solve problems with SDKs.

Now back to tools. As of June 2011, MontaVista has released the content-tools project to the community. Content-tools are used in conjunction with BitBake and OpenEmbedded (OE) to manage content within a project. Combined with an SDK, content-tools allows a developer to generate collections that will easily integrate into the framework that OE provides. Please watch Meld.org over the next month for tutorials on using content-tools.

In the embedded world, we have all been talking about multicore technology for a long while and we have now seen the first large scale wave of adoption of multicore chips, in particular in telecommunications equipment. Typical applications are those needing massive compute power or high data throughput capabilities. In these projects, one of the challenges HW/SW project teams are facing is how to really take advantage of the hardware, be it for control plane applications or for fastpath/data plane applications. Linux is used in many of these projects with good results, but we now know that Linux needs to be pushed way beyond where it is today in order to meet the needs of fast path applications (performance), power management and security. If Linux can be tuned and optimized for multicore use cases, it will reduce the need for additional technologies such as Hypervisors/Supervisors, Real Time Operating Systems, Bare Metal Executives, reducing the complexity and risk of multicore projects.

Where it gets even more interesting is when multicore goes more mainstream, and in particular when used for hardware consolidation, for example combining one board dedicated to a single function like controlling a robot’s motion with one board doing a different function, such as visualization /UI. Here the complexity stems from the legacy code, having to move, port, migrate or re-develop a lot of existing applications. It can be further compounded when some application are certified (and costly to re-certify), large/complex, or old. This is a world many OEMs have not been gearing up for, with specialized development teams focused on different HW platforms, and different OS environments (Windows, RTOS). We are working with the Open Source community, with the silicon vendors and with our customers to expand the applicability of Linux-based technologies, including virtualization, to help (i) with the transitions for consolidation and migration, (ii) take full advantage of the silicon features, and (iii) make things simpler, faster and cheaper.

The recent Linux adoption rate within the automotive infotainment segment shows that Linux has become a viable alternative to traditional RTOSes that used to dominate this market.

Probably the biggest advantage of Linux in the current automotive market is the rapid development cycle and the innovation of the FOSS community in general. On the OS level, Linux has the advantage in providing connectivity – the new protocols in a traditional RTOS environment require porting, increasing both time-to-market and costs because it is a repetitive process for every change. Also, most semiconductor companies provide Linux together with the development boards for their chips. Last but not least, the availability of numerous applications – especially in the multimedia area – is a strong driving force of adoption of Linux in the automotive industry.

Now let’s talk about Linux world domination!  (Seriously)  – It is hard to say that Linux could ever dominate the whole automotive market, as Linux is simply not appropriate for some applications. In other automotive market segments, Linux is a great choice, especially in applications requiring connectivity, multimedia, and graphics. In these areas Linux is definitely here to stay and its acceptance will grow.

So far the automotive devices that use Linux are telematics devices, dashboards, and head units. The Linux acceptance among  those devices is by far most evident in infotainment where we see many head units with announced SOP that are Linux based, many of these being GENIVI compliant devices.  As GENIVI alliance’s specifications, compliance program, and delivered code matures, it will surely make Linux more attractive to the whole industry.

As for telematics, it can be anticipated that many of the traditional telematics functions will merge with the infotainment applications. The word telematics is composed of the words telecommunications and informatics. The broadest meaning would be computers that communicate. In this context infotainment can be viewed as a subset of telematics. The communication part in automotive is obviously wireless. Automotive telematics started in the 1990s with the deployment of specialized data networks like Mobitex (Ericsson) or DataTAC (Motorola), followed by GSM/SMS, GSM data, GPRS, 3G, and onwards. As network speed grows and prices drop, it will become more and more difficult to draw the line that divides telematics and infotainment.

Probably the biggest advantage of Linux in the current automotive market is the rapid development cycle and the innovation of the FOSS community in general. On the OS level, Linux has the advantage in providing connectivity – the new protocols in a traditional RTOS environment require porting, increasing both time-to-market and costs because it is a repetitive process for every change. Also, most semiconductor companies provide Linux together with the development boards for their chips. Last but not least, the availability of numerous applications – especially in the multimedia area – is a strong driving force of adoption of Linux in the automotive industry.

Now let’s talk about Linux world domination!  (Seriously)  – It is hard to say that Linux could ever dominate the whole automotive market, as Linux is simply not appropriate for some applications. In other automotive market segments, Linux is a great choice, especially in applications requiring connectivity, multimedia, and graphics. In these areas Linux is definitely here to stay and its acceptance will grow.

So far the automotive devices that use Linux are telematics devices, dashboards, and head units. The Linux acceptance among  those devices is by far most evident in infotainment where we see many head units with announced SOP that are Linux based, many of these being GENIVI compliant devices.  As GENIVI alliance’s specifications, compliance program, and delivered code matures, it will surely make Linux more attractive to the whole industry.

As for telematics, it can be anticipated that many of the traditional telematics functions will merge with the infotainment applications. The word telematics is composed of the words telecommunications and informatics. The broadest meaning would be computers that communicate. In this context infotainment can be viewed as a subset of telematics. The communication part in automotive is obviously wireless. Automotive telematics started in the 1990s with the deployment of specialized data networks like Mobitex (Ericsson) or DataTAC (Motorola), followed by GSM/SMS, GSM data, GPRS, 3G, and onwards. As network speed grows and prices drop, it will become more and more difficult to draw the line that divides telematics and infotainment.

The presence of the Yocto Project was strong, it started from the moment an attendee opened their conference goodies bag. A thumbdrive containing the toolchain needed to build an image from source and the pre-built images for ARM, MIPS, PPC, x86, and x86_64, along with the Poky Build System (Bernard 1.0 Release) was distributed to all attendees. Yocto Project t-shirts were given away, a Yocto Project Hospitality suite was available to all, and project leader, Dirk Hohndel, delivered the conference keynote with an overview of the Yocto Project. In total there were seven Yocto-specific presentations at the conference. This project has definitely gained considerable momentum since its formal announcement at ELC-Europe six months earlier.

The Yocto Project presence at ELC demonstrates the interest of the Embedded Linux community in tools and build systems necessary to ease the pain of bringing custom Linux distributions to market on consumer devices, the key target of the project. In addition to Yocto, Linaro project team members gave three presentations including a general overview of their work over the last year, a “power debugging” session, and automated validation session. The Meego project was present as well, with a “Birds of a Feather” session and an interesting power management presentation entitled, “Faster Resume For More Energy Savings on MeeGo,” the lessons from which could be applied to any project interested in porting Suspend-to-Disk (s2d) to a new device.

Not to be outdone by the software projects, embedded hardware also made had its share of ELC presentations. These presentations focused on the community-accessible development boards that have come to the fore over the last year. Texas Instruments ARM-based platforms dominated these presentations through the popularity of their BeagleBoard community and burgeoning PandaBoard community. Topics included experience gained while bringing up HDMI displays on the PandaBoard, high-level web interfaces to low-level I/O on the BeagleBoard, and a 3 hour hands-on training session for ARM SoC programming using the BeagleBoard. A particularly interesting presentation was given by a member of TI’s PandaBoard team, David Anders entitled Board BringUp: Open Source Hardware and Software Tools that described the various free and open tools available to independent developers who can’t afford expensive tools such as Logic Analyzers and Oscilloscopes. This presentation offered a call-to-action for Embedded Linux developers to work with open tools, report their successes and failures, and hack existing and new tools to make them better.

If one theme was to be taken from the 2011 Embedded Linux Conference it is that the majority of Embedded Linux development is being sponsored by large companies. I don’t personally see this as a bad thing at all but rather a result of the natural evolution of the Embedded Linux community and industry as the adoption of Linux for development of Consumer Embedded devices has become the default. The silicon vendors recognize that enabling Linux developers to work with their cores can only benefit them in the marketplace. This has resulted in large-scale sponsorship of big projects, such as Yocto, Linaro, and Meego. Similarly, the majority of kernel developers, and open hardware enthusiasts have joined forces with big companies through direct hires and partnerships, to move development forward more rapidly, benefiting everyone.

The 2011 Embedded Linux Conference was a qualified success given the many excellent technical presentations, and community interaction. I highly recommend anyone interested in Embedded Linux to make the effort to attend in the future.
Linux Foundation will hold a European version from October 26 – 28, 2011 in Prague, Czech Republic.

• All presentations can be found on elinux.org.
• Conference schedule can be found at ELC2011 page.

• Texas Instruments BeagleBoard (OMAP3530)
• Texas Instruments AM1808
• Intel Atom
• Freescale i.MX51
• MIPS Malta

These SDKs are available for download now to Meld members (registration is free). Please play with them and let us know what you think!

As I discussed in a webinar just before the show, I had a huge list of sessions to attend (and I used the xxx to organize the list!). There were many overlapping talks, which I and many other people I talked to found unfortunate – despite the pressure it puts on speakers, it is generally best to keep sessions to the same lengths so that people can transition from one to the other without having to leave in the middle.

Obviously there was no way I could attend all of the sessions I planned to, but I did go to a fair number and learned quite a lot. Here are some highlights:

• Wednesday Keynote: