Pengutronix at Embedded World 2020
Yesterday, Embedded World started, in normal times one of the largest trade shows for embedded development in Europe. While many exhibitors (and thus maybe also lots of visitors) have canceled their presence due to the coronavirus, we present our booth and our demo show cases as usual.
For online booth visitors or those that simply want to save trees, our well-known Pengutronix News No. 30 can be found here.
But here we go for our demo showcases:
Design for Mainline
The example board shown contains only off-the-shelf components that are well-supported by mainline Linux (and barebox) drivers.
Here is the recipe how Linux Automation GmbH creates your own, customized HMI board:
- select a System-in-Package Chip like the OSD32MP1x by Octavo Systems to drastically reduce hardware design effort and risk
- add reliable and easy to use storage (eMMC)
- seamlessly integrate an off-the-shelf display and touch unit like the BoTouch by Bopla
- add your own preferred interfaces (i.e. PoE on our demo board, CAN, SPI, ...)
- add graphics acceleration using open source drivers (Etnaviv), MESA (OpenGL) and Qt Quick or web browser
- create a reproducible and open source software stack by providing a (Yocto/PTXdist) Board Support Package (BSP) with a current mainline kernel
- optional: long term maintenance with scheduled update intervals to lower security risks and fight technical debt
CAN - J1939 in Linux Mainline
This is probably the most attractive demo to our visitors. You will be able to spend your time on our booth while playing Tetris, using a tractor control stick or (if you prefer) an ordinary keyboard.
If you choose the tractor control stick, your actions are transferred via the CAN-based communication protocol J1939.
Kurt van Dijck has created an in-kernel implementation for J1939 years ago. But he never made the effort to bring it into the mainline kernel. This year a customer contracted Pengutronix to bring Kurt's implementation into the upstream kernel. This happened with the Linux kernel 5.4.
When J1939 went mainline these things happened:
- The protocol is no longer part of the userspace, but part of the kernel and therefore just another socket interface for all applications. Our customer was able to shrink his application code by 50%, which reduces the maintenance workload.
- Since the initial set of patches the implementation gained some attention from other companies in this industry and new use cases came up that we hadn't had in mind before.
- With our implementation of J1939 available as Open Source vendors can now concentrate on fixing bugs and add new features to this implementation instead of working around the quirks of the closed source stacks.
One part of doing things right is to test the code in kernel CI labs.
So far we got reports from different companies involved into industrial, automotive and security development. For example:
- Google started security and stability test of the J1939 stack to avoid possible vulnerabilities. So far Google detected and reported about 10 issues, which have now been fixed by us.
- We got reports about implementation of Eclipse Titan tests (an industry grade protocol testing framework initially developed by Ericsson)
- Other companies started testing and using the stack. We're looking forward for new use cases, test patterns and bugs :)
This is another proof, that our philosophy can't be too wrong: even a protocol, which appears to be very specific and has it's own niche can benefit from the community.
Open Source Graphics on i.MX8M
Maybe the first thing you will notice is that our well-known video demonstrator features four new videos. What you won't notice is the low CPU load as the QML application is now able to make use of the Hantro hardware video decoder that is found in the i.MX8M. Using hardware acceleration for video decoding is necessary to decode videos in an acceptable resolution for the 4k display.
This demonstrator shows the current feature set that you can get by using mainline Linux, GStreamer, Mesa, and Etnaviv on the i.MX8M.
As in previous years, the hardware is a state-of-the-art in-flight entertainment system. Thus, maybe you will watch videos on this generation of hardware using mainline Linux during one of your next long distance flights.
Automated Testing of Embedded Devices
One important aspect of an efficient and reliable platform maintenance workflow is having tests for the requirements that the system needs to satisfy and being able to automate the testing process.
This is where our open source Python-based hardware abstraction framework labgrid comes into play by driving professional testing equipment.
The demo shows one example on how to fully automate test cases: the device under test (DUT) is a Beagle Bone Black with a speed-controlled motor as demo use case. The Micro SD-Card carrying the BSP is inserted into one of our USB-SD-Muxes. This tool makes it possible to change the contents of the plugged SD card from the test server. The serial port of the DUT is connected to the test server. Additionally, the power of the DUT can be switched using a CAN-Open based switch.
With a hardware setup like this and labgrid as a hardware abstraction layer on top, embedded system testing feels like pure software testing: Test suites can be written in pytest and can be executed by continuous integration systems or can be controlled from virtually everywhere using remote access via SSH.
Fail-Safe Update for Embedded Devices
Performing authenticated and fail-safe updates of devices in the field is a topic of ongoing importance and interest.
Our RAUC updating demonstrator with 6 Raspberry Pis is known to those who visited the Pengutronix booth during the last years but has since received ongoing technology improvements.
In barebox 2020.02.0, for example, the full support for the Raspberry Pi platform went mainline and thus also enables makers to use RAUC for their home automation, video box, or anything else.
The Demo not only shows fail-safe upgrades of devices in the field using the RAUC update framework but also sketches a full rollout scenario by making use of the open source deployment server hawkBit.
For interfacing with RAUC via D-Bus on one side and hawkBit via its DDI API on the other side, we use the simple Python-based example application rauc-hawkbit that also had a new release during the demo preparation.
While the Python implementation is meant for evaluation purposes, thanks to the guys from Prevas DK, there is now also a glib-based C implementation available, called rauc-hawkbit-updater.
At out booth you can also lean more about other current and useful features as
- SmartCard/HSM (PKCS#11) support
- delta updates with casync