Yocto Project

The 1.8 release of the Yocto Project is out, and between lots of other things it brought build capabilities to Toaster. This means that you can at last configure and run your builds with it. If you are a Yocto Project or OpenEmbedded wizard ... [More] , you might be wondering: why would I use this thing at all, if I can do everything from the command line? [Less]

Have you learned about the Yocto Project Developer Day yet? Held annually in conjunction with the Embedded Linux Conference, DevDay is a great way to spend a day learning all about the Yocto Project with hands-on presentations. In addition, you ... [More] go home with the development board of your choice, along with the knowledge to build your own Linux distribution for it. [Less]

  Sometimes the imp of the perverse takes over my fingers as I tap out these little blog posts. Originally I was going to title it: "Oops!  We did it again" I reconsidered it because  There are those who actually want sensible blog post titles so ... [More] they can find the information they need Some people may not understand the Britney Spears reference It was absolutely no accident that we have now shipped 5 public releases of the Yocto Project (v0.9, v1.0, v1.1, v1.2, v1.3) and this latest one is no accident either. In fact, our v1.3 release today is one day earlier than initially planned. And hey, we are an absolutely serious and professional community! I already wrote a couple of posts about the 24 developer-visible features in the v1.3 release and the analysis of our defect trending and over 500 bugs fixed which led us to conclude that this is the highest quality release we have made to date.  We're also seeing continued excellent adoption of the Yocto Project, as more folks realize that it's better to work with the large and growing Yocto Project community for their embedded Linux needs, rather than fight with something repurposed or hacked together. But as proud as I am of the community for delivering such a stunning release, I'm constantly reminded of how far we have yet to go. Much of my time these days is in thinking about our upcoming development work and how we can rise to the challenge of creating the best environment for embedded Linux development. So congratulations to the team for an amazing effort in the Yocto Project v1.3 release! I hope you will download the bits, engage with the community, and help us make embedded Linux even better. [Less]

What's bugging me? I'll tell you what's bugging me. It's when my dashboard dials stop working right. My first car was a 1978 Datsun B210 sedan that I bought when I was in graduate school. It was a very simple vehicle with nothing fancy on it. But it ... [More] did have a few, um, quirks. I bought it in the bitterly cold winter of 1983 and promptly spun it in a 360 degree circle in an intersection in Loveland, Colorado late at night after visiting with my then-fiance (and now wife) Deb. Almost all of my interesting car stories come from that car, whom we had dubbed "Elliot." One time I hopped in Elliot and the gas gauge had moved from near empty to three-fourths full. I was terrified that the fuel level indicator had broken, and I actually had no idea how much gas I really had in the car.  Fortunately, Deb had been nice and had just put some gas in the car and hadn't told me. But it did make for a moment of panic. I believe that the right indicators can be a good way to measure a software project's health. But rather than having 50 different indicators measuring all kinds of things, I like having a very small set of really good ones and asking questions when they are warranted. So you can imagine my shear panic when I saw one of my favorite indicators go non-linear during this development cycle of the Yocto Project. Here is a snapshot of the weighted defect density for the v1.3 development cycle: (You can find the current version on our project wiki in the QA Project page). This is such a simple metric - take the number of open bugs and multiply them by their severity. As we get close to a release, we should see the line slope towards some mutually acceptable level, which in this case is the dotted green line.  It has been clear for some weeks that we would not be hitting that goal. What the heck is going on? Did we goof up how we were counting? Was there a change in the way the metric was calculated? Or (shudder, shudder) is the software really that much buggier? A total failure if we're trying to fix a lot of bugs in this release. My first thought was that we were counting bugs against both the current development effort (v1.3) plus bugs that were in v1.2 and earlier. The answer is yes, but were were always doing that. The red line is a measure of just the bugs found against v1.3. As you can see, this is still pretty non-linear. After a lot of analysis by Song Liu and others, I believe I have an answer: With operating system products from Mentor Graphics and Wind River now with the Yocto Project as its upstream, we have a lot more large-scale commercial usages of the project. This means we have a lot more people banging on the code in more creative ways and breaking some things we never saw before. I believe this means that the bugs were always there, we just didn't know it. Mid-cycle, we added a bunch of new engineers to the project, many of them doing QA work. This meant that often they were submitting "pilot error" bugs or bugs that were duplicates of ones already there. As we analyzed the numbers more deeply, we found that we really had achieved our goal of higher quality as measured by bugs fixed.  So I'm satisfied that we are headed the right direction on the Yocto Project v1.3 release and we can only get better from here. Now we just need to reset our "goals" so our gauges work well again. [Less]

I was having lunch at the recent LinuxCon and Plumbers conference with a colleague, bragging as usual about how much I love my home near Portland, Oregon. He was having none of it - he feels like Boulder, Colorado where he lives is superior and he ... [More] was frankly being belligerent about it. (Imagine that, and he even worked for me for a while!) I suppose there are some things to like about Boulder, but I trudged through hip-deep snow there just last winter. In Portland, people claims it rains all the time, but this summer keeps going on and on. It's good weather to fix bugs in. Why? I think when the sky turns dark and rainy is a perfect time to sit down and think about feature development with absolutely no distractions. You stay inside anyway, so why not develop code? On the other hand, if you get frustrated with the way something was coded or finding a bug, it's nice to get outside and went some steam. Well, that's my theory anyway. And we're fixing bugs like crazy for the next release of the Yocto Project. If you watch the oe-core mailing list or the project Bugzilla, you will see all kinds of activity as patches flow in and bugs get resolved. We stated from the beginning that bug fixing would be a key part of the v1.3 release and indeed it will be. As a reminder, here are the themes we announced for this release: Continuity / Refresh Stabilization & Adoption Usability And true to our word, we will have about 500 bugs fixed in this release. We also have a long list of improvements which will be visible to developers. Here is a list compiled for me by Paul Eggleton. In addition, we have made countless package updates, and a major improvement to both the command line bitbake interface and the graphical developer experience. - eglibc 2.16 - gcc 4.7 - Linux kernel 3.4 - Eliminated intermediate step when building cross compiler toolchain - Mesa can now provide GLES accelerated graphics without X11 - Relocatable SDK - yocto-bsp script for automating the initial parts of creating a new BSP - Buildhistory improvements: better performance, track postinst/postrm scripts - Reduce dependencies between debugging symbol packages - Added doc-pkgs IMAGE_FEATURES feature to install all documentation - Disable sharing shared state between machines using different distros by default to avoid glibc version problems (can be configured) - Python functions now consistently use four spaces for indentation - no more having to try to match the mix of tabs and spaces in your recipes - Enable EFI in grub installer - Fixes to allow qemu-native to be built on host systems without X11 (i.e. for console use only) - Enable python and perl scripting for perf as well as text-mode UI - Added ability to produce a companion SDK together with an image - Add bitbake functionality to force a rebuild of a recipe (new -C and improved -f options) - Improved mirror handling during fetch - allow mirrors of mirrors; handle errors more gracefully - Add script for producing "bootcharts" from buildstats so you can see the timeline of the build - Checksums for local files referred to in SRC_URI are now included in task signatures so that changing their contents causes the relevant tasks to be re-executed - Move from module-init-tools to kmod - Start to add regression tests for BitBake - Add create-recipe script to automate some of the parts of creating a brand new recipe - Add class-* overrides - particularly useful for target/cross/crosssdk but works with all classes That's a pretty significant list! I have been digging into the actual bug data lately, and will write something next time about it. [Less]

The Yocto Project now provides two new layers related to In-Vehicle Infotainment (IVI): meta-ivi and meta-systemd. These layers are contributed and maintained by Wind River Automotive Solutions, as part of Wind River's GENIVI Baseline Integration ... [More] Team (BIT) contribution. The new layers will be maintained in coordination with the releases of metadata layer combinations. meta-ivi is meant to provide long-term support for IVI embedded systems, in concert with GENIVI's commitment to driving the broad adoption of an In-Vehicle Infotainment (IVI) open-source development platform. meta-systemd provides temporary systemd support to solve a short-term structural issue of the GENIVI architecture. It will be maintained until systemd support is merged directly into the core OpenEmbedded metadata, hence obsoleting it. [Less]

The Yocto Project is proud to present a branding compliance program. This program enables individuals or organizations to register as Yocto Project Participants, or to register related projects or products as Yocto Project Compatible. Approved ... [More] registrants receive special badges as well as guidelines for using the Yocto Project brand. For more details, see the Branding Compliance page. Currently registered organizations are on the Branding Compliance Registrar page. [Less]

  When I initially started talking publicly about the fact that I was working on the Yocto Project, one of the first questions I got was, in essence, "Why would you need to build an OS from sources?" After all, there are plenty of distros out there ... [More] who have done the hard work for you. The invention of the binary OS distribution is not a new thing. I remember back in the days of BSD we could boot up a binary image on our VAX 750 and we didn't need to build the OS from sources first. For Linux, there are a plethora of free and commercial distributions, from Fedora, Ubuntu, SuSE and many others. Now don't get me wrong - I love all of these binary distros when used on servers and clients. I have nothing against them and I really adore them. There are just some very serious problems using them on embedded devices. Here's just one: A whole lot of people will install a binary distribution on their target embedded device, add or remove packages, customize their application and then ship the system. There's just one teeny tiny problem with this. It violates the license agreement. Remember the terms of the GPL: any time you redistribute binary code licensed with any version of the GPL, you also need to redistribute all of the sources which are affected by the GPL as well as the build scripts. Although it's possible to find all of the sources when you redistribute a binary distribution plus or minus various packages, it's usually a major pain to collect them all up. And finding the build scripts may be nearly impossible. (And I'm not even getting into the problem of GPL v3 code which adds further restrictions). [1] So one of the major advantages of a system like the Yocto Project is that all of the sources used to build the system are readily available in one location. You can pull up the license manifest and all of the sources and build instructions and make them available with your product. [2] So now when people ask me why I don't like people using conventional distributions of Linux for their embedded devices, I usually tell them I don't want to encourage them to break the law. I don't actually know if violating the terms of a contract (license) is perhaps not the same as breaking the law, but it's pretty much the same to me. So instead of breaking the license - or pulling yourself into a pretzel to try to meet the terms of the GPL with a binary distro - why not just use the right tools for the job and use the Yocto Project!   [1]. I love it when device makers do things the right way, and some do. For example, you can go to Sony's web site and download all of the GPL-licensed code for their products. Way to go! [2]. Of course, if you don't make these sources available online or in an offer, then you are still in violation of the license. We can only do so much in the Yocto Project - you do have to take some responsibility. [Less]

I remember attending a conference in Taiwan one time and managed to squeeze some time in for an early morning run. Taipei is an amazing, modern city with awesome mass transit, bakeries and restaurants and very friendly people. What I found amazing ... [More] though was to run down a random urban lane and suddenly see an ancient-looking temple jammed between high-rise buildings. It's one of the charming things about exploring a new place at street level.   It's same kind of experience you might find in New York City running past St Patrick's Cathedral. A clear reminder that human communities require stability and history, even in the midst of an amazingly creative and changing metropolis.   "Creative" and "innovative" are great words to describe why Linux has become so popular. Since people's innovations are free and freely available to all (and with a license model which ensures this remains so), Linux has attracted the best and brightest inventors and creators. To support this rate of change, the kernel is released on about an 80 day heartbeat. That means you can count on a new version coming out pretty frequently.   However, like Taipei and Manhatten, human communities need something stable in the midst of change. This is particularly true of people trying to base products on Linux. Companies trying to sell hardware need to have something which will remain fairly constant for months and years rather than becoming obsolete.   Historically, this stability has come in the form of Linux distributions. Unlike the kernel alone, a distribution is a complete, working operating system which includes the kernel and a complete set of user space software. Many of the popular distributions for servers and desktops have long-term supported versions which provide the required stability.   The embedded world is totally different. In spite of efforts to squish embedded into the mold of servers or desktops (or cell phones for that matter), the reality is that the common distro model for Linux is not at all appropriate for embedded devices. This is why roughly 80% of embedded devices use a "roll your own" Linux. (Can you imagine running a TV with the same operating system you run on a desktop? Of course not, it's a silly idea).   And this is why we invented the Yocto Project. We believe that if most people are going to create their own roll your own distribution anyway, why not get everyone on the same page with a great build system, and common versions of the kernel and the "grep" command. That way, they can focus their innovation on things that really matter to people.   As a matter of policy, we took the approach with the Yocto Project to deliver the freshest kind of innovation leadership in Linux-based operating systems. This means we Do a full release of the project's software every six months Include in those releases the latest released and stable Linux kernel tool chain and user space which lines up with our six-month beat rate. Make sure we lead in such innovations as btrfs and the like. Monitor the health of that software continuously with our autobuilder, nightly sanity checks, weekly testing, milestone QA and monitoring the defects closely. Since we are an open source project, we can't really hope to provide long-term support for any of our releases beyond a year. We hope our partners in the community will offer longer-term support in their product offerings.    This is why I'm so excited about LTSI. If you havn't heard of it, it's another Linux Foundation project called the Long Term Stability Initiative. In addition to the existing Linux Long Term Support (LTS) kernel, LTSI provides the stability plus innovation that embedded device makers need from Linux. It adds kernel features, SoC support and drivers back-ported from latest mainline in addition to the critical bug fixes and security fixes in LTS.   If you have been tracking the Yocto Project community at all, you will see that we're actively trying to figure out how to collaborate with the LTSI project, so we can bring the best of what that project brings to stability while maintaining the leadership and innovation people have become accustomed to.   And hopefully, this union of innovation and stability won't be an unholy one, but a happy one! [Less]

A couple of weeks ago, we replaced the original heater that was installed when we built our house in 1988. I chronicled that tale in a recent post on this other blog. One of the things I'm really impressed with is the spiffy new thermostat and its ... [More] shinyness. See when you're like me, the thermostat is one of the last things you think too much about. I think our original one was programmable (which saves a lot at night), but it got busted in the chops a few too many times, so had to be replaced with a new programmable control. But this was was subject to all sorts of abuse over the years. I think I remember one of my kids smashing it in frustration. Such violence! The new unit is quite pretty and seems to have some nifty programming options. Since this new equipment is replacing what we had before, it would be a pain if the installer had to run a new wire between the HVAC and the fancy thermostat. But this one is designed to run over the existing four-lead wire that controlled the older system. That's pretty clever - the furnace even supplies power to the touch screen. Of course, I immediately start thinking about what chip and operating system might be behind that lovely piece of touch-sensitive glass. I can't find any reference to "Linux" on the Lennox.com web site, and I'm sure they would have a source offer available if they used GPL software. But what really got me thinking was what else you could do with this system. The HVAC installers asked us if we wanted to wait a few weeks for a new type thermostat which is connected by wifi to the internet. We were told that the new kit would allow us to control our home's temperature from anywhere in the world using our phones or ipads. I can't say I have ever had a time in my life when I wished I could remote control my homes temperature from a browers. (Program the DVR? Yes, many times, but not the temperature). Lennox iComfort WiKFi brochure is here. The brochure shows a lot of young, hip executives with their smart phones controlling the Lennox furnace. (As opposed to the brochure for the thermostat we got which shows a lot of much older people. Boo! We got the old folks thermostat.) Frankly, I am also a little worried about yet another internet-connected embedded device connecting to my home WiFi, which might be poorly firewalled and could be subverted by someone with the intent of doing harm to my home. Can you imagine the spectre of homes all over the world being cranked up to max temperature by some terrorist cell or enemy government? Oh the horror! Oh the humanity! Seriously, it would be much worst to have thermostats subverted into a bot net, or perhaps sniffing for credit card numbers. Another interesting option for smart thermostats is the Nest Thermostat, which does indeed have a source offer available (though there is a link at the top of the page which is broken). So you can see clearly all of the open source software in use, including connman, which is a very cool project that we make use of in the Yocto Project to initiate and manage a variety of network connections. I love the minimalist-retro design of the Nest too. Very low profile and unobtrusive and it's reminiscent of the old dial thermostats of my childhood. I wouldn't mind trying one of these out, though I fear that the complex HVAC I have might not integrate terribly well with a differently smart system. The Nest looks like the perfect project for using the Yocto Project to build and maintain their embedded Linux system. Perhaps they already do, or will do so some day. So I'm guessing Dave Lennox doesn't use Linux, which is unfortunate. But I do wonder what's under the covers. I'm not about to rip apart my new thermostat to find out. Being without heat is something I don't look forward to. I'll leave that research to someone else. [Less]