In this blog post I would like to address the challenges of performing unattended and verified updates of embedded Linux systems in the field using open source software and workflows. While updating is not a end in itself, a second part of my considerations goes even further and also works out the necessities and possible workflows for keeping the software stack of a project up to date and thus either preventing security issues or at least enabling a short reaction time in case of severe CVE'S discovered.
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.
Pengutronix has been to FrOSCon at the University of Applied Sciences Bonn-Rhein-Sieg. This year we had a booth where we presented our Open Source activities and were able to contribute three talks. A booth at an Open Source conference like FrOSCon always opens doors to a lot of interesting conversations with new faces, old friends and colleagues.
Whenever it is a requirement to be able to switch off an embedded device without any previous preparation, the next question is about the consistence of the used filesystem. If this filesystem is used to be written with new content and this new/changed data hasn't done it's way to the persistent media when the power is cut, this new/changed data is lost.
On June, 27th, while the sun was relentlessly heating up Germany as hardly every before, above 50 employees from many companies came together in a well air-conditioned room in the TP ConferenceCenter in Heidelberg. All operating in different fields of application but all involved in embedded systems and all interested to learn something new about security and deploying software updates.
barebox works great on NXP's i.MX platforms. While there is some support for Marvell's mvebu platform, it is not even near being complete. The main limitation is in my eyes that there is no code to initialize RAM settings on these machines.
The Arria10 SoCFPGA can boot from multiple sources: SD Card, NAND flash, QSPI flash and eMMC, that can be selected via the BSEL pins. If the bootrom can not find a valid bootloader on that medium, it will fall back to JTAG. So for developing and testing, the BSEL pins can just be set to a medium that is non-existent. In case of bootstrapping, the bootrom falls back to JTAG anyway, as there is no valid bootloader, yet.
A BSP (Board Support Package) in Embedded Software is the layer of software that lets you run your application on a specific hardware. For Pengutronix a BSP usually contains a bootloader, Linux Kernel and a userspace. DistroKit is our Demo-BSP that supports a variety of common evaluation boards. DistroKit gives you a head start if you want to develop an application on top of such an evaluation board with most of the hard problems already solved.