Este mes casi no llego a mirar los repositorios oficiales en los GitHub de Raspberry Pi. No es que sea algo que esté escondido, la propia documentación de fuentes de software de Raspberry Pi explica de dónde sale cada cosa, e incluso lista sus organizaciones en GitHub. Ahí está casi todo lo que la empresa prepara antes de contarlo en su blog. Cuando quieren que lo sepas, publican una nota. Cuando todavía no, puede escaparse en un commit, aunque desde las filtraciones de la Raspberry Pi 3B+ se volvieron muy prudentes, esto creo que ya lo he dicho por aquí.
El repaso a los GitHub de Raspberry Pi de mayo 2026 no trae hardware escondido entre los commits, a diferencia de marzo (aunque sigue sin haber noticias de esa pantalla de 10″). Pero sí deja una dirección bastante clara, y además bastante coherente con el mes pasado: actualizar dispositivos en campo sin romperlos. El bootloader aprende a tener un plan B. La herramienta de imágenes apunta al mismo objetivo desde el otro lado. Y el kernel se dedica a afinar temas de energía y fiabilidad.
El kernel de Raspberry Pi en mayo: una GPU que aprende a dormir
La rama de desarrollo va por la 6.18.33, con los saltos de estabilidad habituales a lo largo del mes. Pero el cambio que más me ha gustado no es un número de versión, sino una función nueva en el GPU. El driver drm/v3d (el que gobierna el núcleo gráfico V3D de la VideoCore VII y de la VideoCore VI) estrena gestión de energía en tiempo de ejecución.
En la práctica significa que la GPU se apaga sola cuando nadie la usa y vuelve cuando hace falta. No es algo que vayas a notar mirando la pantalla, pero sí en el consumo de una Pi que pasa horas sin dibujar nada. Eso sí, tocar la energía de un bloque gráfico tiene su complejidad: el mismo mes llegan varios parches para vaciar las cachés antes de suspender y para refrescar la TLB de la MMU al despertar. Son el tipo de arreglos que evitan corrupciones raras tras entrar en reposo y encenderse.
Ethernet que se atasca en silencio
El otro asunto interesante para la fiabilidad está en la red. Hay una tanda de «candidate fixes» para un cuelgue silencioso de la transmisión en el BCM2712 y el RP1. Es decir, la conexión de red por cable de la Raspberry Pi 5. El driver macb dejaba de enviar paquetes sin avisar de nada, y reproducir ese fallo no es fácil. Que lo etiqueten como «candidatos» indica que aún lo están persiguiendo.
Por otro lado, la Ethernet de la Pi 4 también recibe atención. El driver bcmgenet mantiene ahora desactivado el ahorro de energía EEE en el buffer de recepción. Además, se revierte una limitación previa del tamaño de ráfaga DMA que daba problemas. En ambos casos la decisión es la misma: ante la duda, fiabilidad antes que microoptimización.
PCIe, NVMe y un guiño al SATA
El almacenamiento de la Pi 5 también suma arreglos. El controlador PCIe conserva ahora ciertos bits de un registro de depuración al negociar la petición de reloj, lo que mejora la estabilidad con discos exigentes. Además, el driver NVMe corrige el acceso a la tabla del Host Memory Buffer en sistemas de 64 bits. Era un fallo de orden de bytes que solo se notaba en arquitectura ARM.
Hay un cambio que me toca de cerca por las pruebas que tengo pendientes con discos SSD. Se revierte parcialmente el parche que forzaba DMA de 32 bits para los controladores JMicron JMB582 y JMB585, los mismos que llevan muchos HAT de discos. Hay un tema de errores o baja velocidad con discos UASP, que precisamente muchas cajas USB externas llevan estos JMicron que son de los mejores.También se deshacen unos cambios en el sensor IMX219 de la Camera Module 2 que habían roto los modos de 480p y 1232p.
rpi-eeprom: el bootloader aprende a tener plan B
Este probablemente sea el cambio más importante del mes. El repositorio del firmware de arranque estrena actualizaciones A/B del bootloader para el BCM2712. La idea, copiada del mundo del móvil, es sencilla: en lugar de sobrescribir el único bootloader que tienes, se mantienen dos copias. Si una actualización sale mal, el sistema arranca con la copia anterior y no te quedas con una Raspberry Pi «brickeada». He aprovechado después de leer la actualización para hacerla en mi Raspberry Pi 5.
Para los que tenemos una Pi en casa para nuestras cosas caseras es un detalle. Para quien gestiona decenas de dispositivos repartidos por ahí, sin teclado ni pantalla a mano, es la diferencia entre actualizar tranquilo o no actualizar nunca. De hecho, encaja con la importancia que los clientes industriales tienen cada vez más peso para las decisiones de Raspberry Pi.
El resto de cambios refuerzan esa misma línea. La Pi 5 pasa a usar la fuente de entropía correcta para el kaslr-seed y el rng-seed. Así mejora la calidad del arranque aleatorizado y de la generación de números aleatorios. La herramienta de criptografía del firmware ya puede leer y escribir el uso de claves en la memoria OTP, una pieza más del arranque firmado. Y en el lado más normal, el firmware SDRAM de Broadcom para la Pi 4 sube a la versión 2.35. También hay nuevas comprobaciones de versión mínima del bootloader.
rpi-image-gen: el mismo objetivo desde el otro lado
Si el bootloader ahora puede actualizarse sin romperse, igual hay que hacer con las imágenes que se le envían. Esa es la tarea de rpi-image-gen, la herramienta que ya comenté en abril como relevo profesional de pi-gen. En mayo ha seguido: el ritmo de commits es alto y casi todos van en la misma dirección.
Lo más llamativo es el trabajo en torno a las actualizaciones OTA con esquema A/B aplicado a la imagen entera, no solo al bootloader. Es justo lo que necesitas si quieres conservar la configuración del usuario al cambiar de versión, como pasa también en las actualizaciones de los teléfonos móviles. Llega también soporte de raíz cifrada, una nueva capa base para Trixie pensada para sistemas interactivos, y gestión de Wi-Fi con iwd incluyendo el código de país.
También se actualiza el generador de SBOM, ese inventario de software que acompaña a cada imagen para saber qué lleva instalado y qué vulnerabilidades te afectan. En conjunto, rpi-image-gen se va pareciendo cada vez menos a un script de aficionado y cada vez más a la cadena de montaje de un producto industrial.
Una última cosa. Dado que el AMA de Reddit de este mes puso la Raspberry Pi 6 en boca de todos, he buscado a lo burro. No hay nada: nada de nuevo chip, nada de archivos DTS de placa nueva, sin directorio de dispositivo en rpi-image-gen. Cuando la Pi 5 se acercaba, los commits hablaban meses antes del anuncio. La Touch Display de 10,1 pulgadas también se coló en el kernel con bastante antelación. Aquí el silencio es total. O el desarrollo inicial de la Pi 6 ocurre en repos privados, o el anuncio está más lejos de realmente empezar a mover algo.
Mayo no trae muchas cosas nuevas. Pero si trabajo para los usuarios que siguen comprando Raspberry Pi aunque estén caras, las empresas: bootloader con plan B, imágenes que se actualizan por aire sin perder los datos, raíz cifrada, entropía decente y una GPU que se apaga cuando no hace nada. Raspberry Pi sigue mejorando una plataforma para gente que despliega dispositivos, no solo para quien trastea un domingo. Y lo bueno es que casi todo eso nos acaba beneficiando.
Si quieres mirar tú mismo, el material está en abierto: el árbol del kernel, el repositorio del bootloader, el firmware y la propia herramienta rpi-image-gen. Nos leemos en el repaso de junio.
