La comunidad detrás del Raspberry Pi (y por extensión, de Linux) ha dado lugar a una extraordinaria cantidad de desarrollos, pero si hay un elemento con el que mantiene una dura batalla, es el código propietario asociado al módulo de vídeo VideoCore IV de Broadcom presente en todos los modelos del ordenador. El clásico atajo para obtener funcionalidad es lo que muchos llaman un «blob», sin embargo, la desarrolladora Kristina Brooks publicó un bootloader preliminar que busca romper ese candado en el Raspberry Pi.
La Free Software Foundation describe a la necesidad de código propietario para inicializar correctamente a un Raspberry Pi como «falla fatal». Por supuesto, la FSF extiende la misma cortesía a todo hardware que se encuentra en una situación similar, aunque debemos reconocer que el duelo entre la comunidad y el VPU Broadcom VideoCore IV se ha extendido por mucho más tiempo del que imaginamos en un principio (el Raspberry Pi lleva más de cuatro años en el mercado). Los beneficios del Raspberry Pi son lo suficientemente grandes como para dejar a un lado esta restricción técnica, pero si el objetivo es hacer «más abierta» a la plataforma, tarde o temprano habrá que cruzar espadas con ella.
[amazon box=”B07BDR5PDW”]
A eso apunta el reciente trabajo de la programadora Kristina Brooks, quien publicó en GitHub un bootloader open source para el VPU en el Raspberry Pi. La descripción oficial nos habla de un pequeño firmware con la capacidad de inicializar UART, el PLL del VPU, y ARM. La idea es que este nuevo código reemplace al bootcode.bin que encontramos en la tarjeta SD del Raspberry Pi, y ya fue evaluado en las tres generaciones principales del ordenador. Brooks explica que es necesario tener UART si se espera alguna clase de salida, y quedan varios problemas por resolver, entre ellos el uso adecuado de los núcleos en los nuevos modelos del RPi.
De más está decirlo, el desarrollo se encuentra bastante lejos de poder bootear Linux, y desde cierto punto de vista, creo que es más lógico colocar al bootloader al nivel de una prueba de concepto. La dirección del proyecto es la correcta, y tanto Brooks como el resto de los colaboradores mencionados en la página de GitHub han hecho un formidable trabajo, incluyendo la propia Broadcom por liberar los «headers». Aspectos críticos al estilo de aceleración por hardware y soporte para códecs aún se encuentran en el tintero, y puede que nunca lleguen a una posición óptima, pero con paciencia, esfuerzo, y mayor colaboración, seguramente veremos un Raspberry Pi más abierto de lo que es hoy.
