Tag Archive for: open source

How Mender works

/in , /by

by Tom Rini, VP Engineering

Software Update solutions are a key part of our services offering. For open source over-the-air updates, we often we recommend and work with mender.io. In fact, Konsulko Group is a Mender Authorized Referral Partner. Recently, a prospective customer expressed an interest in knowing more about how Mender works. Here’s the brief, informal introduction to member.io that I prepared, and now I’m sharing with you.

—

As a high level starting point, https://mender.io/how-it-works provides a good overview of what’s supported and what it covers. In short, Mender starts off by providing support for a traditional “A/B” approach to system updates, where if the update isn’t marked as valid (and there’s hooks for the application(s) to verify the system before this is done), it’s assumed invalid and the system will roll-back automatically. While “OTA” implies over the network, it can just as easily be done by providing (and validating) a USB key that contains an update.

One of the reasons we recommend Mender is that it has very good in-depth documentation. The starting point for all of that is https://docs.mender.io/2.4/ which covers all of the topic starting from how to implement Mender support in a device and including how to create your own server infrastructure if you don’t want to use their paid service. While there are a number of important pages there, one that I like to highlight is https://docs.mender.io/2.4/artifacts/state-scripts as it shows the state machine for an update and talks about some of the common use cases that come up for user interaction or dealing with failures.

Another place I want to call out is https://docs.mender.io/2.4/devices/update-modules which is also mentioned in the first link. This is how Mender is extended to provide updates for other parts of the system that are not the rootfs itself.  Since updating a Docker container is something that has been mentioned before I want to also note https://hub.mender.io/t/docker/324 as it is a well supported module for this specific case.

I hope you find this information useful. Please contact us if you have specific questions. We’re looking forward to talking to you about your own specific OTA needs.

Time to sign up for Virtual ELC Europe 2020

/in /by

Join us at the Linux Foundation’s Embedded Linux Conference Europe, the premier vendor-neutral technical conference for embedded Linux developers, presented virtually on October 26–29, 2020.

Konsulko Group’s Leon Anavi will give a talk on Software Update Solutions for Yocto Project and OpenEmbedded, exploring the integration in Yocto and OpenEmbedded of A/B and binary delta updates over the air or through a USB stick.

No matter where you are in the world, here’s a good chance to experience ELC Europe for a fraction of the cost of the in-person event.

Helping Yocto Project work with Python 3

/in , , /by

According to the statistics from StackOverflow Python is the fastest-growing major programming language. First released in 1991, Python is nowadays commonly used for various applications in multiple different industries. Python is a first class citizen of many embedded Linux systems.

The Yocto Project, a collaborative project of the Linux Foundation for creating custom Linux distributions for embedded devices, uses the OpenEmbedded build system and relies on layer meta-python from meta-openembedded to deliver Python 3 packages. Until recently, meta-python was providing both python 2 and python 3 versions of each package. The Python community decided that January 1, 2020, was the day to sunset Python 2. Since then Python 2 has been officially deprecated. This triggered major changes related to the support in Yocto and OpenEmbedded. All recipes for version 2 were moved to layer meta-python2 to provide legacy support after the end of life for this Python release. In meta-openembedded/meta-python, the OpenEmbedded community started efforts to remove all recipes for version 2 as well as to consolidate inc and bb files into a single bb file for version 3.

Konsulko Group engineers are regular contributors to various upstream open source projects, including meta-openembedded and more specifically to meta-python. In the past month, Leon Anavi joined the community efforts for consolidating Python 3 recipes in a single file as well as for upgrading various packages. Nowadays, most of the Python 3 recipes are utilizing the pypi bbclass which takes care for downloading and processing packages from pypi.org. This makes most of the upgrades to new releases of a Python package straight-forward. However, it is important to check the list of build and runtime dependencies as well as to ensure that bitbake still works fine with the upgraded recipe version for both x86-64 and ARM architectures prior to submission. 

Let’s have a closer look at the recipe python3-protobuf. It has been recently upgraded from version 3.11.3 to version 3.12.2. Protocol Buffers, also known as protobuf, are Google’s language-neutral, platform-neutral, extensible mechanism for serializing structured data. In the Yocto and OpenEmbedded ecosystem, recipe python3-protobuf depends on recipe protobuf from layer meta-oe. Both meta-oe and meta-python are part of meta-openembedded. So to avoid version mismatch and to ensure that bitbake will be able to successfully build python3-protobuf version 3.12.2 an upgrade of recipe protofobuf to the same version was mandatory. We contributed both upgrades to the master branch of the git repository meta-openembedded. The maintainers took care of cherry-picking them to the dunfell branch which is compatible with the latest stable release of the Yocto Project as of the moment. As a result, if you checkout the latest stable release of Poky, the reference system of the Yocto Project, and meta-openembedded you will be able to quickly build the latest version of protobuf and python3-protobuf out of the box.

Konsulko engineers have been there since the earliest days of the OpenEmbedded build framework and the Yocto Project. We continue to regularly make upstream contributions to these open source projects. Please contact us if you need your “own” Linux distro for your own embedded product.

Getting some help with build systems

/in /by

One of the most rewarding parts of working at Konsulko Group has been our returning customers. Months, sometimes years, after we’ve successfully completed an engagement, we’ll hear from the same client (sometimes at the same company, sometimes at a new one) that they would like Konsulko’s help on their latest project.

Konsulko engineers have decades of experience at all levels of open source embedded software, from Linux kernel and low-level subsystems, through middleware and application development, to QA, maintenance and tools, but it is our expertise with the Yocto Project/OpenEmbedded build system that’s usually a part of everything we do.

From the time it first appeared in 2003, the OpenEmbedded build framework revolutionized embedded development, providing a systematic and reusable way to build custom Linux distributions for unique embedded devices. Almost ten years ago, OE became the build system of Yocto Project, and OE’s “recipe” approach was further structured and enhanced by layers.

Konsulko engineers have been there since the earliest days. We’ve seen a lot, learned a lot, and apply our expertise to helping our customers – old and new – build their “own” Linux distro for their own product.

ELC goes virtual

/in /by

Registration is now open for Embedded Linux Conference (ELC), the premier vendor-neutral technical conference of developers working on embedded Linux. Held virtually this year on June 29 – July 2, 2020, ELC will feature four full days of education, collaboration, and deep dive learning opportunities presented from locations across the globe.

Konsulko Group engineers are scheduled to give two sessions. CTO Matt Porter will teach his popular tutorial, Introduction to IIO and Input Drivers, and Principal Software Engineer Paul Barker will be giving a talk as part of the Project Mini-Summits.

Although we won’t be able to literally “see” you there, we hope you will join us in supporting the virtual edition of this important Linux Foundation event.

Working remotely by design

/in /by

The coronavirus pandemic has forced all of us to fundamentally change the way we live. Thankfully, at Konsulko Group, it has yet to significantly change the way we work. Working remotely is the norm for Konsulko engineers. In fact, Konsulko was built on the idea of Globally Employable Engineers™ based throughout the world.

We all have permanent personal workspaces that are fully equipped with the best tools for remote development work and collaboration. Members of our team have years of software engineering experience, excellent English language skills, and are comfortable working directly with our customers.

In these times when travel is necessarily limited and in-person meetings can endanger health and safety, we are happy to share our best practices based on our extensive experience as remote workers. Please feel free to contact us.

Meanwhile, we continue our work in the open source community while helping our customers build great products for the better times ahead. Stay healthy.

See you at FOSDEM

/in /by

Konsulko Group engineers will be attending FOSDEM ’20 on February 1 & 2. Look for us during the conference around the Automotive Grade Linux and OpenEmbedded stands, or at Leon Anavi’s presentation on Saturday, Building Homebridge with the Yocto Project. Hope we see you in Brussels!

The Year in Review 2019

/in /by

Konsulko Group has completed another busy year, working hard to solve our customers’ problems, while building efficient and reliable open source software for their products in development.

We’ve helped our customers launch exciting new products across the spectrum of embedded systems: automotive, medical devices, networking equipment, and cutting-edge consumer electronics.

As Globally Employable Engineers, we are geographically distributed across North America and Europe, but thanks to today’s technology, we have worked together every day as a team, often in real time.

At Konsulko Group we believe production software should be closely aligned with OSS community work upstream, and we work to make that happen. Our community work in key open source projects includes the Linux kernel, Yocto Project, OpenEmbedded and Automotive Grade Linux. We participate in important OSS conferences like FOSDEM and SCaLE, sponsor TuxCon and OpenFest every year, and have published two new “how to” technical papers, useful to developers at all levels (available on this website).

We’ve continued our close relationship with the Linux Foundation and Automotive Grade Linux, supporting AGL development, demos and member meetings. Konsulko Group gave technical talks at ALS Tokyo, ELC San Diego, ELCE and Yocto Project Summit Lyon, and the AGL AMM Monte Carlo, and participated in the OSLS Half Moon Bay.

Through the Embedded Apprentice Linux Engineer program, Konsulko provided well-received training sessions in 2019 at SCaLE 17x Pasadena, ELC San Diego and ELCE Lyon. We’ve given on-site and remote training to major companies in North America, and remain a Linux Foundation Authorized Training Partner.

All in all, 2019 seems like it has gone quickly. We now look forward to working with you in 2020 and beyond.

Hope to see you at the AGL booth at CES

/in /by

Automotive Grade Linux (AGL) is a collaborative open source project accelerating development of a fully open software platform for automotive applications. At CES 2020, AGL will be highlighting both members and the broader AGL ecosystem, demonstrating connected car services, audio innovations, instrument cluster applications, security solutions and more, all running on the AGL open source software platform.

Again this year, Konsulko Group will be supporting the AGL booth at CES [Westgate (Tech East) Smart Cities, booth 1815]. Come see us during the show or at the AGL Evening Reception on Wednesday, January 8 from 6:00pm – 8:00pm.

Building a DIY SOHO router, 6 months on

/in , , /by

Building a DIY SOHO router using the Yocto Project build system OpenEmbedded, 6 months on

A little more than six months ago, I posted part 4 of our series on making a SOHO router using the Yocto Project and OpenEmbedded. After 6 months of deployment, this is a good time to follow up on how the router has worked out in residential use.  The zeus code-name Yocto Project release was just announced, and that means that the release we started out with in part 1 is now close to being out of support.  That’s not a problem since we designed in support for moving to new software releases using Mender to deliver software updates.

One of the most important metrics in a project like this is, how does it perform?  From the standpoint of a family of 4 heavy internet users, it’s gone really well.  The WiFi range is only a little better than before, but that’s not really a function of the software.  Making everyone use Pi-hole has only resulted in a small number of places where I needed to override the blacklist and allow something in.  From an end-user point of view, this has worked as well as any off-the-shelf router.  From the administrator point of view, I’ve done scheduled maintenance during the day on a weekend, and it really did take only the 5 minutes I promised everyone rather than turning into one of those worst case scenarios where something broke and it takes an hour to fix it.  In fact, the update portion of the plan has gone exceedingly well.  While I didn’t make a post about moving to warrior from thud, I did that transition a while ago and it went smoothly.  Mender introduced a change that required attention be paid while migrating, but it was documented and went smoothly.  On the metadata side, the upgrade was as easy as one could hope.  A few of the bbappend files needed to be updated for a new version, and some of the changes I had made and pushed upstream as part of the original series were now just included, so they got dropped from my layer.

One of the things I touched on in the series was about using the update functionality to test development changes in a production environment.  The chance to do that came up with a systemd-networkd issue that was a problem in my local setup.  The upstream project requested people verify the problem exists with newer versions of systemd and a new enough version was available in what would become zeus.  So I made a quick weekend project of doing an update of my layers to build with a newer version of all of the metadata, removed the work-around, and flashed the image in place.  A quick reboot confirmed that the issue was indeed fixed, and then rather than commit to running an otherwise in-progress release I simply rebooted and automatically rolled back to my stable release.  With the network back up again, I updated the issue in upstream Bugzilla to let them know the problem was fixed.  After a bit longer, a few other people also confirmed it worked for them and now the issue is resolved.

In terms of the metadata itself, there have been a few clean-ups to what I did in my own layer with each release update I’ve done.  In the series I left out what hardware I was building on, and I also left out talking about using the linux–yocto recipe.  Since I first wrote the series linux-yocto has become easier to use, and I found this as part of reviewing my own changes like they were brand new with each upgrade.  I was setting some variables that initially didn’t have reasonable default values, and now they do and I don’t need to set them myself.  This in fact means that moving forward, rather than a version-specific kernel bbappend file, I can go with an always-used one to enable the additional kernel CONFIG options that I need for a time-based firewall.

I started out by mentioning that zeus has been released, and I’m working on migrating to it as I write this.  In fact, it’s so new that I’m doing my own little port of the meta-mender core layer to zeus for my needs. I expect that by the time I do my first update from one build of zeus to the next there will be an official update I’ll be able to use instead.  Looking forward, this was a great little project that also was a lot of fun.  The goals I set way back at the start have been met, and I’m happier with my network than I have been in a long time.  Of course, the list of features an off-the-shelf system provides is always growing, and there’s now monitoring and display items on my weekend project list now to keep up.  I foresee using and improving this setup for a long time to come.

Tag Archive for: open source