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.

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.
Back to technical showcases

Further Readings

Showcase: Continuous Testing

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.

Showcase: Remote Working

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.

USB-SD-Mux now reads SD Card registers

The USB-SD-Mux is designed to make life easier for embedded software engineers by automating the transfer of an SD card between a host PC (deploying a new software image to the SD card) and an embedded Linux device. Since we have introduced this device into our Embedded Linux development workflow back in 2019 we have probably written thousands of SD card images with it. Now the usbsdmux software controlling the device has gained a new feature: It can now read and decode a few SD card information registers. This makes it possible to gain more insight into the capabilities of the used SD card - especially while developing on low-level software and drivers interfacing with the SD card.

umpf - Git on a New Level

Modern software development is commonly accompanied by a version control system like Git in order to have changes to the source code being documented in a traceable manner. Furthermore, any version state should be easily reproducible at any time. However, for work on complex projects such as the BSP ("Board Support Package") of an embedded system with its multiple development aspects, the simple stacking of the individual changes on top of each other does not scale.

LXA USB-T1L ❤️ Beagle Play: Exploring Single Wire Ethernet

It seems everybody is talking about Single Pair Ethernet (SPE) these days. So we want to follow the trend and do the same :-) SPE is a class of Ethernet transmission standards that uses just a single pair of twisted pair cable for data transmission. There are multiple SPE variants spanning maximum data rates from a hand full MBit/s to multiple GBit/s and cable lengths from a hand full of meters to kilometers. The most interesting ones from our embedded-centric point of view are 10Base-T1L (point-to-point, up to 1 km), 10Base-T1S (multidrop, approx. 10 m) and 100Base-T1 (point-to-point, 15 m). The new Beagle Play comes with a 10Base-T1L PHY. This makes it a great peer to experiment with our Linux Automation USB-T1L. In this post we will explore the possibilities of 10Base-T1L on a recent Linux system.

Pulse Width Modulation (PWM) is easy, isn't it? - Turning it off and on again

Part of Uwe Kleine-König's work at Pengutronix is to review PWM (Pulse Width Modulation) drivers. In addition, he also sometimes refactors existing drivers and the Linux kernel PWM subsystem in general.

Yes we CAN... add new features

Have you ever experienced an otherwise fine product that is missing just the one feature you need for your application?

DSA in Barebox

The v2022.05.0 Release of barebox introduced initial support for the Distributed Switch Architecture (DSA) Framework. DSA is originally a subsystem from the Linux Kernel, which exposes the individual ports of a network switch IC as virtual network interfaces.

Pengutronix at Embedded World 2022

Welcome to our booth at the Embedded World 2022 in Nürnberg!

First Steps using the candleLight

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.