Recently, we have been evaluating Continuous Integration (CI) systems for a variety of projects (both OSS and customer). There are many OSS options to chose from. Because we already use Docker containers for Yocto/OE builds, Concourse and Drone made the short list. Both communities seem responsive and helpful.Read More »Drone for Continuous Integration
As Embedded Systems become more complex, the complexity of the process to build the software for these systems also increases. As humans, our ability to deal with complexity is limited, so we develop tools and processes to manage the complexity. In the end, these tools and processes are about constraints and patterns. A well-designed tool or process encourages you to do things in a way that is consistent and maintainable, which leads to reliable and predictable results.Read More »Accepting Constraints in Build Systems
Recently I was asked by a developer, who has done windows development for 10 years, how to get started with Embedded Linux. Embedded Linux covers a lot of ground and includes a broad range of components/skills to put together an entire system. Below are a few suggestions.Read More »Getting started with Embedded Linux
When building a product using Linux, versioning and branching of your software is an important consideration. Everyone’s needs are different depending on the size of the team, culture, and testing requirements, so there is no one size that fits all. However, after working on a number of different projects for a dozen or so different companies, there are several practices that are often used.
As we work with larger and more complex systems (i.e. Linux), more and more of our time is spent on integration and pulling different pieces together. We often need to debug or understand code we did not write — especially in build systems. To work effectively in this scenario you must be able to quickly search through a lot of source code. Therefore, we are always looking for ways to make this more efficient.
Why Docker? When using OE to build software for products, we often run into the scenario where software needs to be built using the same version of OpenEmbedded over the course of several years. Production builds need to be predictable. We’ve also observed that old versions of OE often break as new Linux distros come out. This is just the result of the complexity of building tool chains. Additionally, for predictable builds you really don’t want to be changing the build OS. This requirement automatically rules out Arch Linux, Debian Unstable, Gentoo, etc as production build machines. Additionally, having developers debug OE build issues on varying workstation distributions is frustrating and time consuming.
I’ve already written about using autotools and qmake in OE. With recent projects, we’re using CMake to build most C/C++ components. Like any good tool, CMake has a learning curve, but it seems to do its job quite well. Below are examples of a CMake build file, and corresponding OE recipe.
With the BEC OE build template, you can easily set up an opkg feed server that serves up packages from your build directory. This allows… Read More »Setting up an OpenEmbedded Package Feed Server
During development with OpenEmbedded (oe-core, meta-oe, meta-angstrom), I often find it useful to set up a feed server so that packages can quickly be installed… Read More »A quick way to set up an OpenEmbedded feed server
Noticed the following when browsing around in the OpenEmbedded sources the other day: ROOTFS_POSTPROCESS_COMMAND += “openssh_allow_empty_password ;” This allows a blank password for development, which… Read More »OpenEmbedded: configuring openssh to allow a blank password
During development, often a blank root password is used for the embedded Linux target system. However, when deploying an embedded Linux system, often there is… Read More »Setting the root password in an OpenEmbedded image