Esta idea de repasar los GitHub de Raspberry Pi suelen tener un problema: informan de commits sueltos sin saber a dónde van a parar. Este mes es distinto ya que ayer, 1 de julio, sin embargo, Raspberry Pi ha publicado un anuncio oficial. Ese texto ayuda a entender el trabajo que se veía en los commits de junio. Así que, por una vez, podemos contar el final antes que el resto. Hasta ese momento no parecía haber nada interesante, hay que tener en cuenta que es verano en el hemisferio norte, donde se produce menos por estar más pendiente de otras cosas.
El protagonista es rpi-sb-provisioner en su versión 2.3. ( OJO hoy 2/7/2026 ya hay una v2.3.1) Es la herramienta de preparación de arranque seguro que usan las empresas para fabricar dispositivos con Raspberry Pi en serie. No es un tema para quien graba una tarjeta SD en casa, pero explica hacia dónde empuja la compañía. Y de paso conecta varias piezas que en repasos anteriores aparecían por separado. Vamos por ese hilo primero y luego repasamos lo demás.
rpi-sb-provisioner 2.3: la herramienta de fábrica que va tomando forma
Conviene situar la herramienta. Por ejemplo, Raspberry Pi lanzó la primera versión en 2024 como una simple colección de scripts. Servían para instalar un sistema operativo con arranque seguro y cifrado de disco completo. Desde entonces ha crecido bastante. Hoy incluye una base de datos de fabricación, un registro de auditoría y una interfaz web. Cada cambio, según cuenta la propia empresa, respondía a un problema concreto que le trasladaban los usuarios.
La versión 2.3 añade tres integraciones que encajan justo con lo que se veía en los commits del mes. La primera es Raspberry Pi Connect for Organisations. Permite dar a cada dispositivo una identidad inmutable que sobrevive a las actualizaciones y a los reinicios de fábrica. Además, la conecta a una cuenta de organización sin asociar las placas una a una a mano. Cuando fabricas miles de unidades, ese paso manual es justo el cuello de botella que no te puedes permitir.
La segunda es la preparación por descripción de imagen, o IDP, que llega desde rpi-image-gen. Hasta ahora la herramienta daba por hecho que partías de una imagen tradicional derivada de Raspberry Pi OS. Con IDP puedes describir diseños de particiones más complejos, e incluso preparar sistemas que no se crearon con rpi-image-gen. La idea que resume el anuncio es directa: si puedes describirlo, puedes prepararlo.
rpi-fw-crypto: el cifrado que ya se veía en los commits
La tercera integración es rpi-fw-crypto, y aquí es donde el repaso de junio y el anuncio oficial se solapan del todo. Este mecanismo permite usar criptografía asimétrica sin exponer la clave privada única de cada dispositivo. La 2.3 lo aprovecha por duplicado. En el servidor de preparación cifra y conecta el material de firma —un fichero PEM o el PIN de un HSM— al propio servidor. Y en el dispositivo, además, participa en el cálculo de la clave de cifrado de disco completo.
Esto enlaza con algo que ya se veía en los commits del bootloader. En el firmware del BCM2712 apareció el bloqueo de claves por operación. Concretamente, permite bloquear por separado la lectura, la firma, el HMAC, el uso de clave o su generación. En paralelo, rpi-sb-provisioner movió su gestión de claves de OpenSSL al estándar PKCS#11. Así delega las operaciones criptográficas en un módulo dedicado, en lugar de manejar las claves en memoria de proceso.
Puedes revisar el detalle en la documentación de preparación masiva y en las notas de versión del proyecto. En cualquier caso, la lectura de fondo es clara. Para Raspberry Pi, la seguridad del arranque se ha vuelto una pieza central de cómo quiere que las empresas fabriquen con su hardware.
El kernel rpi-6.18.y: el V3D arregla cosas y luego deshace una
Dejando la fábrica a un lado, el kernel siguió con su ritmo habitual. La rama activa es la rpi-6.18.y. El trabajo más denso llegó del driver drm/v3d, que gobierna el núcleo gráfico V3D de la VideoCore VII. Maíra Canal, de Igalia, firmó tres correcciones seguidas sobre el envío de trabajo al compute shader. Concretamente, la primera evita que un envío indirecto con recuentos de grupo de trabajo en cero llegue a ejecutarse. Antes, un cero en cualquiera de las tres dimensiones se interpretaba como 65.536. La segunda tapa una fuga de memoria asociada a ese mismo caso. Y la tercera corrige el contador de referencias del monitor de rendimiento global, que se quedaba sin liberar en varias rutas.
Hasta aquí, tres parches. Pero el 19 de junio el árbol revirtió uno de los cambios de finales de mayo. Por ahora, toca esperar a la siguiente fusión con la rama estable para saber si vuelve con otro enfoque.
La cámara conectada por RP1 hace el mismo vaivén
El driver rp1-cfe, el front-end de cámara del RP1, repitió el patrón. Corrigieron varias cosas del formato RGB y luego se revirtió un parche anterior. En la práctica, quien use una cámara con salida RGB directa en la Pi 5 debería notar menos artefactos de color. Aun así, conviene seguir probando antes de dar el problema por cerrado.
Además, hay un cambio pequeño en código pero grande en utilidad. El kernel activa soporte de configuración para los chips Wi-Fi MT7921 y MT7922 de MediaTek. Están presentes en bastantes adaptadores USB y módulos M.2 baratos que hasta ahora requerían parches de terceros o directamente no funcionaban con la imagen oficial. Es de esos arreglos que no salen en ningún titular, pero que resuelven una tarde de frustración a mucha gente.
Como Asociado de Amazon, gano por compras calificadas. Este enlace es un enlace de afiliado, lo que significa que puedo ganar una comisión si realizas una compra a través de estos enlaces, sin costo adicional para ti.
rpi-eeprom y rpi-image-gen
El bootloader también estrenó una herramienta pendiente desde hacía tiempo: rpi-bootloader-version. Lee la versión directamente del árbol de dispositivos, en lugar de depender de vcgencmd. De hecho, el propio rpi-eeprom-update usa esa vía desde hace años. Sin embargo, buena parte de la documentación —incluidas las guías de este blog— seguía recomendando vcgencmd bootloader_version. Así que toca actualizar esas referencias.
rpi-image-gen alimenta el nuevo IDP
Por su parte, rpi-image-gen es el motor detrás del IDP que estrena la 2.3. Este mes sumó una caché de paquetes apt entre construcciones, muy útil en integración continua, y validación de versiones más estricta para su sistema de capas. Además, añadió soporte para NetworkManager como capa de red alternativa. Y corrigió el generador de enlaces simbólicos del reparto de particiones (image-rota), relacionado con el esquema A/B que comentamos en mayo.
Junio deja dos velocidades del mismo proyecto. Por un lado, una capa gráfica —el V3D y la cámara del RP1— que sigue puliéndose a base de arreglar y deshacer, sin cerrar del todo. Por otro, una capa de seguridad —el bootloader, rpi-fw-crypto y rpi-sb-provisioner 2.3— que avanza y que ya tiene su propio anuncio oficial. Cuando algo pasa de los commits sueltos a la portada del blog de Raspberry Pi, suele ser una señal importante. A mí me queda claro que primero van los usuarios comerciales y después vamos los aficionados a la electrónica y el DIY.
Si quieres mirarlo de primera mano, ahí están el árbol del kernel, el bootloader, rpi-sb-provisioner y rpi-image-gen, todos listados en la página oficial de fuentes de software. Ya veremos el repaso de julio, como ya he dicho al principio, es verano por aquí y lo mismo hay poco que contar.
Repositorios consultados
- raspberrypi/rpi-sb-provisioner — Aprovisionamiento de arranque seguro, versión 2.3
- raspberrypi/linux — Árbol del kernel, rama
rpi-6.18.y - raspberrypi/rpi-eeprom — Bootloader para Pi 4 y Pi 5
- raspberrypi/rpi-image-gen — Generador de imágenes y motor del IDP
