Why Blobs Are Important, And Why You Should Care

We are extremely happy to live in a time when hardware with amazing capabilities can only be owned for a few dollars. Systems that would once have taken an expensive pile of chips and discretion, along with months of development time to assemble, are now integrated into commodity silicon. Whether it’s a chip system or a microcontroller with Linux capability, peripherals like WiFi, GPUs, Bluetooth or USB stacks now come as part of the chip, just another software library, not a ton of additional hardware.

Beware of Blob!

ESP-01 module
The cheapest chip still comes with a stain.

If you have to pay a price for this convenience, it comes in the form of a stain. Part of pre-compiled binary software that does the hard work of talking to hardware and that provides a unified software API. Whether you’re talking to ESP32 WiFi through an Arduino library or loading a Raspberry Pi with a Linux distribution, while your code may be available or even open source, the spot it relies on is closed and patented. This is a challenge not only for Software Libre enthusiasts looking for a real open source computer, but for the rest of us, because we remain committed to the desire of the hardware manufacturer to update and patch its patches.

An open source defender would say that the solution is easy, manufacturers just need to make their open source stains. And that’s true, if all the spots are open source, then the Software Libre crowd would be happy and their open source nature would make it easier to generate these updates and patches. So why don’t manufacturers release their spots as open source? In some cases, this may be due to a closed mindset of never releasing anything to the world to protect the company’s intellectual property, but leaving it is not a complete answer. To fully understand why this is so, it’s worth looking at how our multifunction chips are made.

The chips are not made as before

Motorola 68000 shot
He knew where you were, with 68k. Pauli Rautakorpi, CC BY 3.0.

Decades ago, a new microcomputer and its range of peripheral chips would have been designed entirely in-house by a team of engineers hired by the company. Chips like the Intel 8086 or Motorola 68000 were manufactured this way and in many cases would even be placed on silicon from in-house chip factories. Today’s semiconductor industry is much more fragmented and works very differently. Although some large companies can still do all the work internally, they are much more likely to buy components of their new products as parts of IP, such as software in the form of VHDL, or similar hardware description languages. It’s entirely possible to design a complete SoC this way without owning an IP, and companies like ARM have become the dominant players in the industry, selling their cores to chip developers. Such a chip assembled from the finished IP can then be sent to a chip factory in a third party for production, which means that a complete product line of chips can be sold without direct ownership of either the IP or the factory.

A chip assembled from multiple commercial IPs will, of course, be subject to all individual component licensing agreements. Individual IP owners will have many reasons to insert restrictive clauses in their agreements, but at the most basic level they seek not to disclose trade secrets to their competitors in the aggravated industry. It is therefore provided that the block controlling the peripheral of this chip will be bound by a clause in the license agreement restricting the dissemination of information related to its hardware. The blob remains a pre-compiled closed source binary, and no restriction by the open source chip maker will change that. Even chips that contain open source components, such as the RISC-V core, are not immune to also containing a closed peripheral IP, as is the case with on Bouffalo Labs BL602 WiFi SOC.

It’s all in the updates

Raspberry Pi Model B from 2012
Even the earliest Raspberry Pi Model B from 2012 can work with the latest Raspberry Pi OS, thanks to the updated spots.

So open source defenders have an answer as to why stains exist and why they won’t go away any time soon, although it may not be to everyone’s liking, at least it’s valid. But the problem of stains doesn’t stop there, and maybe our community should think about it, too. Because even if you don’t have a problem with your hardware that requires a stain, its presence can still come back to bite you. The reason may have as much to do with the open source world as it does with the IP owner or manufacturer.

If you have a Raspberry Pi, you may have updated your copy of Raspbian or Raspberry Pi OS several times with newer versions that include major updates to their Linux kernel. Raspberry Pi’s Broadcom SoC is just like all other chips, as it comes with a stain, and when they release a new core, it will be in a firmware package customized for use with this spot and will also come with all the appropriate blob updates. The Raspberry Pi people will have the sources of the closed source bits, but they are prevented from releasing them through their agreement with Broadcom, which gave them access to the blob source. That way, the Raspberry Pi has up-to-date software, but it’s a nasty combination of an open source operating system that relies on a closed source component to work.

Now compare the Raspberry Pi to a lesser-known single-board computer, say a ten-dollar board with a name that follows the {SomeFruit} Pi naming scheme. The Raspberry Pi may have less exciting specs, but if you look at the operating system that comes with the board outside the brand, you’ll find that it has a very similar custom core that relies on a stain. The difference will come as long as you continue to use it, over time there may be no new kernels released, and after a while you will use an ancient version of the kernel with no prospect of upgrading.

Even if you don’t have a nameless dashboard, you’ll recognize the same problem if you have an Android phone. This is a powerful Linux-powered computer running a custom Linux distributor, but after a few years your chances of a new version of Android are really slim and you’ll have almost zero chance of installing another Linux distribution without tricks involving user land. chroot and whatever old Android kernel it has installed.

Both examples have the stain at the root of their problems, as both come from manufacturers who have no interest in releasing new custom cores for their stains, so both are slowly disappearing.

What do you think is open source?

Yunsup Lee owns a prototype RISC V chip. At UC Berkeley Par Lab Winter Retreat, January 2013.
Yunsup Lee owns a prototype RISC V chip. At UC Berkeley Par Lab Winter Retreat, January 2013, Derrick Coetzee, CC0.

When asking what can be done to alleviate this situation, it is worth considering what role open source software can play. We have established the semiconductor IP industry as the root of the fact that there is no zero manufacturers to make their blob code open source, but how can the open source world react to this? This boils down to a question of open source philosophy, which is probably reflected in the choice of license; Is there open source software that works in conjunction with closed source components, or is there software to extend open source to all angles of calculation and turn off closed source? In the case of Linux, it targets the latter, with the interface that the blob needs to talk to changing with each version of the kernel, forcing the blob developer to update or leave the age of their distribution irrelevant. Raspberry Pi developers have put their efforts as a key feature of their products, but this is not a priority for many hardware manufacturers. If other operating systems, such as Microsoft Windows, can keep driver compatibility low in their versions, why can’t their open source alternatives?

Of course, there is another potential result. Semiconductor manufacturers prefer things that cost them less money, and as can be seen with the current slow emergence of RISC-V cores, they are showing signs of wanting to dip their finger in the water when it comes to hardware chip components with open code. A quick look OpenCores or LibreCores will reveal a wealth of parts that can be freely added to the design, so there is at least the possibility of a SoC without its own IP that needs a stain. More than the mere existence of such resources will be needed to persuade the manufacturer to take a step, but for a fully open source chip to be a practical proposition, it must not only have components for all the functions of the chip, but they must also be reliable enough for production. Even with the best of intentions, these two things can take a while to happen.

I hope this article gives you food for thought about the role of the stain on modern chips and its relationship to open source software. This goes beyond the simple argument that manufacturers should just release their blob sources, but if the blob situation can’t be changed, should the open source world adapt to deal with it? As always, we would love to hear your feedback in the comments.