Showcase: Embedded off-the-shelf
A firmware upgrade is due. A newly implemented feature needs to be rolled out, a security issue patched or new hardware support added. The software, while capable, is complex. Pengutronix' strategy to handle this complexity is working on a version- controlled Board Support Package (BSP) with continuous updates and tests on the latest mainline Linux kernel.
But let's have a look on the complexity and customer needs first.
Once Upon a Time
Maybe you have heard of this following scenario, maybe you know it all too well...
The schedule is tight and shortcuts are taken. On update, some components collide with each other, some are fixed and some are left not upgraded. Best case, some security issues are identified and fixes backported. Another component was forked long ago to support a then new hardware feature, but now years later these changes conflict with the upstream project's current state and require much effort to reconcile. The bulk was provided by the vendor's enablement Board Support Package, but now vendor interest is in future products and attracting new customers. Personnel changes at the vendor and at one's own company mean that knowledge of some of the arcane ways is lost and debugging takes more and more time.
With the main stakeholder nearly absent, all past decisions burden those still maintaining derivative software in the field. While their number still motivates the hardware vendor to schedule production runs, the maintenance burden is still carried by each on their own as problems are individually identified and patched.
As if this isn't enough, given a long enough product lifetime, sourcing hardware component replacements becomes increasingly harder over time, which only compounds the software maintenance overhead.
While the trend towards ever-increasing software complexity and demand for both connectivity and security, makes this issue more acute, it's far from being a new realization. The effect of technical debt is well known, but the consequences of the balance struck between quick prototyping and doing things "right" are usually felt only much later.
How can we support you?
As an Embedded Linux Consultancy, Pengutronix has gained a lot of experience helping customers restructure technical debt over the years.
We know, that a long-term maintainable product starts at the very first ideas and decisions. We also know that the development of hardware and software needs to get hand in hand. Therefore, we can to help you as early as possible on a project, which means reviewing schematics and consulting on component decisions.
While the hardware department develops a prototype, the software architecture needs to be designed as well. We will help you build a Board Support Package that is exactly tailored to your hardware and fits your needs. We will add missing drivers and software components in test driven development and ensure that your BSP is reproducible.
Once your product is released, we will help you to keep it maintained through continuous testing and secure updates.
Case Study: The Linux Automation MC-1
Our technical demonstrator is designed to fit a wide range of use cases: It might be a control panel for monitoring your domestic infrastructure (like your solar panels or door bells). It might be an information or entertaining system within your vehicle or anything else you like to imagine.
Thus display support was a requirement, as well as a network link, since all IoT-devices need a network connection ;-) And if we have a network connection, we can use Power over Ethernet to power the device.
One last requirement: The board shall be small enough to fit into the backside of the display.
The example board shown contains only off-the-shelf components that are well-supported by mainline Linux drivers.
Therefore initial effort for designing the circuit for this prototype was about two weeks and another week to bring up the entire software stack. This was possible by a thoughtful selection of components, which we want to present to you right know:
- Possible SoCs are not only evaluated by their feature set, price and availability, but also by the openness of documentation and existing upstream support. For this PoE powered display controller, the STM32MP1 checks all boxes.
- The OSD32MP1x makes it easy to bridge IT to the physical world. With eMMC storage added, one already has a full-fledged Linux Computer; on a low-layer-count PCB.
- Upstream support for the board was contributed to the Linux Kernel, ARM Trusted Firmware and barebox bootloader projects. No software components need to be patched to get a Linux system running.
- A BSP collects configuration parameters and definitive versions of all software components used. Software releases can be reproduced years later.
- The BSP builds on top of community efforts like Yocto or PTXdist where many entities collaborate on updating the different components while maintaining compatibility.
- The graphic pipeline powered by Etnaviv, maintained by Pengutronix in the Linux kernel, provides users with a familiar environment: Graphic Toolkits akin to what you would do on a standard Linux desktop PC.
- New software is continuously deployed to the board and test suites run to catch regressions during development.
- To give feedback on regressions as early as possible to kernel developers, the board is being integrated into the KernelCI infrastructure, which notifies Linux Kernel Maintainers of breakages caused by new patches.
About 70,000 patches go into the Linux kernel every year, and many of them are bug fixes. The same applies to most other open source projects that are part of a modern Linux system. In order to benefit from the work in the community, the sensible strategy is to constantly update to the latest software version and keep the system up to date. Of course, with this amount of changes, new bugs can be added or incompatibilities can arise.
Project work with our customers includes the handling of hardware prototypes. Since work is generally done in parallel, on many project for many customers, there is a constant flood of hardware prototypes accumulating on the desks of our developers. These accumulations of loose boards can become a problem. This is especially the case when a number of people work on a prototype. Another common annoyance occurs when a project has not been worked on for a period of time, as this might involve moving the hardware from one desk (or storage location) to another and setting it up again. Right now, in a situation where working from home is more common and relevant than ever, this has become even more of an issue. The distances between desks and storage locations of our developers are now measured in kilometers, rather than meters.
When designing an embedded system, one must consider both the application and the underlying hardware in combination, if the intended long-term stability is to be achieved. While we discussed the necessity of software updates in previous posts, in this article I describe a way to use a memory subsystem corresponding to its physics to achieve the best retention and lifetime of the whole system.
The Corona crisis is a challenge that has hit many people as well as most companies quite unexpectedly. The entire team of Pengutronix wants to thank those that currently ensure our essential supplies, health system and civil infrastructure!
Computer programs and code can be protected by copyright law. In Germany this protection cannot be removed. The German Copyright (German: Urheberrecht) grants all right to whoever created the work. Following only this general rule, only the developer could use, modify, share the code he wrote.
Today it has been 15 years since we mainlined support for Freescale/NXP's i.MX architecture in the Linux kernel! That was one small step for [a] man, one giant leap for (industrial Linux users') mankind :-) Here is some background about why it happened and what you might want to learn from history for your next embedded Linux project.
Once the bootloader on your embedded device is up and running the development of kernel and userland in PTXdist-based BSPs is usually based on booting from network. Thus there is no need for the developer to write the boot media with a new image.
While the development on an embedded system I need to reboot it quite often. Doing so I appreciate to keep the required steps as less as possible and be sure the embedded system uses the recently changed data in a consistent manner.
Simplify and beautify your developer's life. An example.