How to react to risk?

Back in 2004, Pengutronix was contacted by a customer who developed a medical device: they had selected a nice CPU for their new hardware, all relevant peripherals matched the requirements and the chip manufacturer promised 14 years of device availability for that shiny MX1. In fact, MX1 was the first ARM based processor from Freescale, still labeled as "DragonBall" at that time (which was the marketing name of the previous series of M68k based devices), contained a 200 MHz ARM920T core and looked like a perfect choice for the job. Marketing material had a check mark at "Linux Support", so what could possibly go wrong...

At the time we got contacted, someone had asked Freescale if they also provide reliable operating system software support for those 14 years, and it quickly turned out that the Linux port was an "Enablement BSP", made to show that the hardware was operable. However, as a medical device manufacturer, there are strong regulatory processes in place which in fact makes it absolutely necessary that you are able to react if some kind of risk turns up. So what do you do if, for instance, a security flaw in the kernel is found during that 14 years? You could port the i.MX1 patches forward to a newer kernel that contains fixes, but this plan quickly turned out to be impossible. Hundreds of patches had been stacked to an already old kernel at that time, with less than optimal topic separation and documentation, so the effort for even understanding what had to be done was unacceptable. Even worse, like almost all vendor code at that time, the kernel port had been made without talking to the community or reviewing the patches due to confidentiality reasons.

So what should our customer do? Everyone was absolutely convinced that it would be impossible for a small project team to make a mainline port, taken that obviously not even a big chip manufacturer was in a position to do that.

So we sat in the office and thought: Challenge accepted!

Taking back control with the power of Open Source

When we were asked for assistance, we quickly found out that, while there was a lot of code for all the many peripherals in i.MX1, our customer fortunately only used a small subset for his actual project. We analyzed the patches carefully, ripped them apart, sorted them into interesting and non-interesting pieces, modified the better ones and rewrote other parts of the port and moved all that on top of the latest mainline kernel. It took us about 6 weeks to have a first mainline based kernel. Linux code is licensed under the terms of the GPLv2, so modifying other people's kernel code was always legally possible, so even we as just-a-few-random-hackers were allowed to just do what was necessary without lengthy discussions with the legal teams of big companies. After the six weeks, we had a port that was good enough to actually work for the customer, and even good enough to be posted on the Linux ARM Kernel Mailing List (LAKML). Patches were discussed, reviewed by other kernel hackers, improvements had been added, and finally we proposed the patch stack to be included in the mainline kernel.

After some time, we were asked if Sascha Hauer would be interested in being the official i.MX maintainer, we agreed and during the next years all the i.MX patches went through our hands. MX27, MX31, MX25, MX51 and finally MX53 brought us many new industrial projects: the word spread quickly in the industrial community that this mainline port was of high software quality. In fact, it was not us being some magic genius, but simply because of the development process of the Linux kernel that makes best use of the community's technology-focussed quality process and involves many, many smart people out there to focus all that expertise in one mainline kernel.

Happy birthday, i.MX Mainline Port!

Many industrial device manufacturers based their product development on mainline since then - with and without our help. After a while, Freescale joined the community and let many of their developers contribute to the mainline kernel and even to the maintenance effort.

The community grew, i.MX6 got a big success story in the industry. With Etnaviv and the VPU drivers, open source support for the 3D GPU and the video encoders/decoders were added, and today we are working on mainline support for i.MX8M.

Finally, even today, 15 years after the first port, a top-of-tree 5.3-rc kernel is still able to boot on i.MX1 with only minor modifications (see a screencast of a boot from today below)

Happy birthday, i.MX!

Screencast