Społeczność wokół Raspberry Pi (a przez rozszerzenie także Linuxa) wygenerowała ogromną liczbę projektów, ale jest jeden element, z którym toczy się ciężka walka – zamknięty kod związany z modułem graficznym VideoCore IV firmy Broadcom, obecnym we wszystkich modelach tego komputera. Klasycznym obejściem dla uzyskania funkcjonalności jest tzw. „blob”, jednak programistka Kristina Brooks opublikowała wstępny bootloader, który ma przełamać tę blokadę na Raspberry Pi.
Problem zamkniętego kodu
Free Software Foundation opisuje potrzebę użycia zamkniętego kodu do prawidłowej inicjalizacji Raspberry Pi jako „fatalną wadę”. Oczywiście FSF stosuje tę samą ocenę do każdego sprzętu w podobnej sytuacji, ale trzeba przyznać, że pojedynek między społecznością a VPU Broadcom VideoCore IV ciągnie się zdecydowanie dłużej, niż początkowo przypuszczano (Raspberry Pi jest na rynku od ponad czterech lat). Zalety Raspberry Pi są na tyle duże, że można tę techniczną restrykcję pominąć, ale jeśli celem jest uczynienie platformy „bardziej otwartą”, prędzej czy później trzeba będzie się z nią zmierzyć.
Wolny bootloader dla VPU
Do tego zmierza najnowsza praca programistki Kristiny Brooks, która opublikowała na GitHubie wolny bootloader dla VPU w Raspberry Pi. Oficjalny opis mówi o niewielkim firmware, które potrafi zainicjalizować UART, PLL VPU oraz ARM. Chodzi o to, aby ten nowy kod zastąpił plik bootcode.bin znajdujący się na karcie SD Raspberry Pi, i został już przetestowany na trzech głównych generacjach tego komputera. Brooks wyjaśnia, że do uzyskania jakiegokolwiek wyjścia potrzebny jest UART, a do rozwiązania pozostaje kilka problemów, w tym odpowiednie wykorzystanie rdzeni w nowszych modelach RPi.
Nie trzeba dodawać, że projekt jest wciąż daleki od możliwości uruchomienia Linuksa, a z pewnego punktu widzenia rozsądniejsze jest traktowanie bootloadera jako dowodu koncepcji. Kierunek jest właściwy, a Brooks i pozostali współpracownicy wymienieni na stronie GitHub wykonali świetną robotę, w tym sama Broadcom za udostępnienie „headerów”. Krytyczne aspekty, takie jak akceleracja sprzętowa czy wsparcie dla kodeków, wciąż czekają na realizację i być może nigdy nie osiągną optymalnego poziomu, ale z cierpliwością, wysiłkiem i większą współpracą z pewnością doczekamy się bardziej otwartego Raspberry Pi niż dzisiaj.
