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.
Unter dem Motto "Voll verteilt" finden die Chemnitzer Linux Tage auch 2022 im virtuellen Raum statt. Wie auch im letzten Jahr, könnt ihr uns in der bunten Pixelwelt des Workadventures treffen und auf einen Schnack über Linux, Open Source, oder neue Entwicklungen vorbei kommen.
So you went and got yourself one of our fancy rocket-penguin branded CandleLight dongles or, being the die hard hacker you are, went and soldered one up in your toaster oven labeled "not food safe". What's next then? How do you use this thing? Let's answer these question by grabbing a Raspberry Pi and exploring some of the possibilities.
End of January systemd 250 was added to Debian bullseye backports. With a lots of new features and fixes now comes the possibility to set the timing of CAN bus interfaces with systemd-networkd. In this blogpost I will take a look at why this helps us maintain our embedded Linux labs.
2022 has started, and although Corona had a huge impact on our workflow, the Pengutronix team again made quite some contributions to the Linux kernel. The last kernel release in 2020 was 5.10, the last one in 2021 was 5.15, so let's have a look at what happened in between.
Distributionen wie Raspbian lassen die passgenaue Zusammenstellung eines Betriebssystems kinderleicht aussehen. Image herunterladen, Pakete installieren, noch ein paar Änderungen - fertig. Alles wie auf dem Laptop oder Server. Warum ein Betriebssystem aus einer klassischen Distribution im Produkt-Kontext zur Katastrophe führen kann, beleuchtet der Vortrag "Raspbian vs. Build-Systeme: Das richtige Werkzeug für solide Produkte".
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.