The community behind the Raspberry Pi (and by extension, Linux) has given rise to an extraordinary number of developments, but if there is one element with which it maintains a hard battle, it is proprietary code associated with Broadcom's VideoCore IV video module present in all models of the computer. The classic shortcut to obtain functionality is what many call a "blob"; however, developer Kristina Brooks has published a preliminary bootloader that seeks to break that lock on the Raspberry Pi.
The Free Software Foundation describes the need for proprietary code to properly initialize a Raspberry Pi as a fatal flaw. Of course, the FSF extends the same courtesy to all hardware in a similar situation, although we must admit that the battle between the community and Broadcom's VideoCore IV VPU has lasted much longer than we initially imagined (the Raspberry Pi has been on the market for more than four years). The benefits of the Raspberry Pi are great enough to set aside this technical restriction, but if the goal is to make the platform "more open", sooner or later we will have to clash with it.
That's what developer Kristina Brooks' recent work points to, who published on GitHub an open-source bootloader for the VPU on the Raspberry Pi. The official description tells us about a small firmware with the ability to initialize UART, the VPU's PLL, and ARM. The idea is that this new code will replace bootcode.bin found on the Raspberry Pi's SD card, and it has already been tested on the three main generations of the computer. Brooks explains that UART is necessary if any kind of output is expected, and there are several problems to solve, including the proper use of the cores on the new RPi models.
It goes without saying that the development is quite far from being able to boot Linux, and from a certain point of view, I think it is more logical to place the bootloader at the level of a proof of concept. The direction of the project is correct, and both Brooks and the rest of the collaborators mentioned on the GitHub page have done a formidable job, including Broadcom itself for releasing the "headers". Critical aspects such as hardware acceleration and codec support are still pending, and they may never reach an optimal position, but with patience, effort, and greater collaboration, we will surely see a more open Raspberry Pi than it is today.
