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.

In cooperation with our spin-off Linux Automation GmbH and our partners Octavo Systems and Bopla we present a proof of concept for the Design for Mainline strategy.

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.