--- title: "NVIDIA prepara a Linux para su próxima generación de GPU: el nuevo driver abierto “Nova” adopta el registro Boot42 y allana el camino más allá de Blackwell" description: "NVIDIA ha empezado a mover ficha en un frente clave para el ecosistema Linux: la compatibilidad temprana de sus próximas GPU “post-Blackwell” a través de Nova , el nuevo controlador gráfico de kernel..." url: https://revistacloud.com/nvidia-prepara-a-linux-para-su-proxima-generacion-de-gpu-el-nuevo-driver-abierto-nova-adopta-el-registro-boot42-y-allana-el-camino-mas-alla-de-blackwell/ date: 2025-10-26 modified: 2025-10-26 author: "Antonio" image: https://revistacloud.com/wp-content/uploads/2025/09/NVIDIA-Vera-Rubin-NVL144-with-Tray.jpg categories: ["Noticias"] tags: ["Blackwell", "boot42", "GPU", "linux", "NVIDIA", "open source"] type: post lang: es --- # NVIDIA prepara a Linux para su próxima generación de GPU: el nuevo driver abierto “Nova” adopta el registro Boot42 y allana el camino más allá de Blackwell NVIDIA ha empezado a mover ficha en un frente clave para el ecosistema Linux: la compatibilidad temprana de sus próximas GPU “post-Blackwell” a través de **Nova**, el nuevo controlador gráfico de kernel escrito en **Rust** que la compañía desarrolla de forma abierta y con vocación *upstream*. En un paquete de parches remitido a las listas de correo del kernel, los ingenieros de la firma introducen soporte para un cambio de bajo nivel pero de enorme calado: el tránsito desde el histórico **NV_PMC_BOOT_0** al **NV_PMC_BOOT_42** como registro de referencia para identificar arquitectura y revisión de los chips venideros. La implicación es directa: **las generaciones futuras dejarán a cero el viejo `BOOT_0`** y usarán **`BOOT_42`** como fuente de verdad para esa información. La [serie de parches](https://lists.freedesktop.org/archives/nouveau/2025-October/049873.html) —firmada por **John Hubbard**— no es una curiosidad técnica más. Es, en palabras del propio ingeniero, una adaptación necesaria para que Nova “**reclame**” de forma estable a **Turing y posteriores** y, al mismo tiempo, **esté lista para las GPU siguientes a Blackwell**, que en la rumorología de la industria se agrupan bajo el nombre clave **Rubin**. En términos prácticos, el cambio reescribe la **lógica de selección** del driver y documenta, en orden cronológico, **cómo** han evolucionado los registros de arranque de las GPU de NVIDIA y **cómo** debe comportarse el código según la era arquitectónica. ![gpu noa add boot 42](https://revistacloud.com/wp-content/uploads/2025/10/gpu-noa-add-boot-42.jpg)*Screenshot* ## ¿Qué es exactamente Nova y por qué importa? Nova es el intento de NVIDIA de dar un salto generacional en su presencia *open source* en Linux. Se trata de un **driver de kernel escrito en Rust**, pensado para **GPU con GSP** (*GPU System Processor*) y llamado a convertirse en el **sucesor de Nouveau** en el árbol principal del kernel para las generaciones modernas (arrancando en **Turing/RTX 20** y cubriendo **Ampere**, **Ada** y **Blackwell**). Su estrategia técnica combina dos objetivos: **seguridad/robustez** (apoyándose en las garantías de memoria y concurrencia de Rust) y **alineación con la hoja de ruta de NVIDIA**, que desde Turing exige la presencia del **firmware GSP** para ciertas funciones de bajo nivel. Aunque todavía está en construcción, Nova representa una **apuesta inédita** de NVIDIA por **desarrollar a la vista de la comunidad** bloques críticos del soporte Linux, publicando parches en las listas del kernel e integrando comentarios *upstream*. En ese contexto se enmarca la adopción de **BOOT42**, un detalle aparentemente arcano que, sin embargo, resulta imprescindible para que el driver **reconozca** y **configure** correctamente las GPU que vendrán después de Blackwell. ## De *BOOT0* a *BOOT42*: un cambio de llave para la próxima era Hasta ahora, el registro **`NV_PMC_BOOT_0`** contenía información de **arquitectura** y **revisión** de la GPU. Nova —como cualquier otro software que necesite saber **qué** silicio tiene delante— consultaba ese registro para decidir **rutas de inicialización** y **tablas** específicas de cada familia (desde NV04 a Turing/Ampere/Ada/Blackwell). El paquete de parches divulgado por NVIDIA establece que los futuros chips **no** usarán ya `BOOT_0` para ese cometido; en su lugar, la información vivirá en **`NV_PMC_BOOT_42`**, mientras **`BOOT_0` quedará en cero**. El cambio no es solo una sustitución de direcciones: obliga a **simplificar** y **endurecer** la lógica de detección para que funcione **de Turing en adelante** sin depender de *ifs* frágiles. De hecho, el *diff* que acompaña a la serie **elimina tipos** como **`Spec`** y **`Revision`** y recorta unas **33 líneas netas** de código, reforzando la claridad del módulo que maneja la enumeración de GPU y su *bring-up*. La propia **nota de portada** de la serie explica que, con esta estrategia, **Nova podrá reclamar Turing y posteriores “de forma predecible durante un buen tiempo”** sin nuevos cambios en esa pieza. ## Contexto industrial: el valor de llegar a tiempo al kernel En los últimos años, el soporte gráfico de NVIDIA en Linux ha avanzado en dos planos: por un lado, el **driver propietario** (módulo binario) que la compañía libera para sus gamas GeForce/Quadro/Data Center; por otro, el ecosistema **abierto (*Nouveau*)**, tradicionalmente limitado por la falta de documentación y por la dependencia de **firmware**. Nova busca **puentear** esa brecha en las GPU modernas con **Rust**, **GSP** y una **colaboración upstream** más fluida, reduciendo la distancia entre lo que llega al kernel principal y lo que los usuarios pueden ejecutar en distribuciones *mainstream*. El hecho de que **los primeros parches “post-Blackwell” aparezcan tan pronto** es significativo por dos razones. Primero, sugiere que **los equipos de Linux en NVIDIA trabajan con visibilidad suficiente** de su siguiente arquitectura como para **acondicionar** hoy las capas comunes del driver. Segundo, implica una **madurez** en el proceso interno: cuando cambias la **fuente de identidad** de la GPU (de `BOOT_0` a `BOOT_42`), tiene sentido **ajustar** cuanto antes todo el código que depende de esa señal para evitar “deuda” técnica cuando lleguen las primeras muestras de silicio. ## Qué puede esperar el usuario de Linux (y qué no, todavía) Conviene separar el titular de las expectativas. **Estos parches no traen soporte funcional** para Rubin ni activan mágicamente un rendimiento superior en tus GPU actuales. Son, más bien, **obras de infraestructura**: preparan el camino para que, cuando las primeras tarjetas de la **siguiente generación** aparezcan, el kernel **sepa quiénes son** y **por dónde empezar** a inicializarlas. Para los **usuarios finales**, lo tangible a corto plazo será limitado. Sin embargo, para **distribuidores**, **mantenedores** y **desarrolladores** del ecosistema, el cambio es una señal útil: - **Distribuciones** que siguen de cerca el *mainline* podrán **integrar** pronto estos cambios y **validar** que no rompen la detección en Turing/Ampere/Ada/Blackwell. - **Proyectos de *userspace*** (Mesa, Wayland/GBM, *window managers*) pueden anticipar **nombres** y **rutas** que afecten a *udev rules*, identificación de dispositivos y *quirks*. - **Herramientas de diagnóstico** y **telemetría** podrán incorporar la noción de `BOOT_42` para sus informes en sistemas de próxima hornada. En paralelo, sigue abierta la **gran cuestión**: cómo de **rápido** y **completo** será el soporte operativo de Nova para las nuevas GPU **una vez estén en la calle**. La historia del soporte abierto de NVIDIA ha sido gradual y, en ocasiones, conservadora en cuanto a **aceleración 3D**, **gestión de energía** o **funciones avanzadas**. Que Nova nazca en **Rust** y con **enfoque upstream** no garantiza milagros, pero sí **mejores cimientos** para iterar. ## ¿Qué hay de Blackwell… y de Rubin? Aunque NVIDIA no entra a nombrar públicamente la arquitectura posterior a **Blackwell**, distintos observadores del código y medios especializados interpretan este “**next-gen**” como una referencia a **Rubin**, el nombre en clave que circularía internamente para la siguiente generación. En la propia documentación de los parches se habla de **Turing a Blackwell** como generaciones que se siguen apoyando en `BOOT_0`, y de las **posteriores** como las que pasarán a **`BOOT_42`** con `BOOT_0` **a cero**. Es, por tanto, una marca técnica de “**más allá de Blackwell**”. Desde el punto de vista de **compatibilidad**, la modificación en Nova pretende que el driver **reclame** desde **Turing** en adelante, por lo que **no** afecta a series anteriores (NV4x, Tesla, Fermi, Kepler, Maxwell, Pascal), donde **Nouveau** seguirá siendo el camino natural. En las GPUs modernas con **GSP** (Turing+), la teoría es que Nova se convierta con el tiempo en el **driver de referencia** en el kernel principal. ## Seguridad, Rust y limpieza de código La decisión de escribir Nova en **Rust** no es cosmética. En el terreno de drivers de kernel, donde un **desbordamiento**, una **doble liberación** o una **condición de carrera** pueden convertirse en **vulnerabilidades graves**, las garantías del lenguaje —**propiedad de memoria**, **préstamos**, ***lifetimes***— reducen superficies enteras de fallo. La serie de parches que acompaña la adopción de `BOOT_42` **elimina tipos** y **simplifica** la lógica de selección, una señal de que el equipo está tratando de **pagar deuda técnica** y **dejar el terreno preparado** para un futuro en el que esa ruta no se toque en años. ## Impacto en el desarrollo de software y herramientas Las aplicaciones y *toolchains* que interactúan con la GPU a bajo nivel —desde **sistemas de *provisioning*** y **monitoreo de flotas** hasta **diagnóstico de hardware**— tendrán que **actualizar su lógica** si dependían del contenido de `NV_PMC_BOOT_0`. En entornos **corporativos** donde se automatizan **inventarios** y **controles de cumplimiento** por familia de GPU, convendrá añadir **detección doble** (BOOT0/BOOT42) hasta que la base instalada de Rubin y siguientes lo haga imprescindible. Para los **proyectos de terceros** que aspiran a integrar con Nova, la recomendación evidente es **seguir de cerca** las listas de correo y el repositorio correspondiente, dado que las **APIs internas** y los **nombres de constantes/registros** están en pleno movimiento para acomodar este y otros cambios. La buena noticia es que el trabajo se está realizando **a la vista de todos**, lo que facilita comentar, proponer y **evitar sorpresas**. ## ¿Qué puede venir después? Si NVIDIA mantiene el ritmo, veremos más parches que extiendan **tablas**, **rutas de inicialización** y **capas de gestión de energía** orientadas a los primeros *samples* de la siguiente generación. También es razonable esperar **documentación** adicional en el árbol de código de Nova que explique **cómo** se debe interpretar `BOOT42`, **qué bits** codifican familia/revisión y **qué combinaciones** distinguen arquitecturas. En paralelo, el trabajo para **Blackwell** seguirá su curso en Nova y en el driver propietario —con el horario que marquen los lanzamientos comerciales—. ## Recomendaciones para usuarios y *early adopters* en Linux - **Sigue el *mainline***: si te gusta probar cosas nuevas, compila kernels recientes o usa una *distro* *rolling* para recibir pronto estos parches y verificar estabilidad en Turing/Ada/Blackwell. - **Observa el *dmesg***: cuando aterrices una build con Nova actualizado, revisa mensajes de **detección** e **inicialización** de GPU; ahí verás si el código “reclama” correctamente tu dispositivo. - **Mantén expectativas realistas**: esto **no** es una mejora de rendimiento, sino un **pilar** para reconocer futuras GPU. El soporte funcional y 3D completo llegará con más iteraciones. - **Participa**: si detectas regresiones en identificación, *reporta* con `lspci -nn`, *dmesg* y versiones exactas del kernel; tu caso puede ayudar a pulir la transición. --- ## Preguntas frecuentes **¿Qué es `NV_PMC_BOOT_42` y por qué reemplaza a `BOOT_0`?** `NV_PMC_BOOT_42` es un **registro de arranque** que, en las próximas GPU de NVIDIA, **almacenará** los detalles de **arquitectura y revisión** del chip. Históricamente esa información residía en **`NV_PMC_BOOT_0`**, pero en las generaciones **post-Blackwell** `BOOT_0` **se quedará a cero**. Nova actualiza su lógica para **leer `BOOT_42`** y así identificar correctamente las GPU nuevas. **¿Qué diferencia hay entre Nova y Nouveau en Linux?** **Nouveau** es el driver abierto tradicional para GPU de NVIDIA y lleva años en el **kernel mainline**, con soporte amplio pero limitado por la ausencia de ciertos componentes propietarios. **Nova** es un **driver nuevo escrito en Rust**, orientado a GPU con **GSP** (Turing y posteriores), que NVIDIA desarrolla **a la vista** de la comunidad con la intención de **sustituir** progresivamente a Nouveau en las generaciones modernas. **¿Significa esto que mi GPU actual será más rápida o más compatible?** No de forma inmediata. Los parches anunciados **preparan** el driver para **reconocer** futuras GPU y **simplifican** la detección de arquitecturas en Turing→Blackwell. Las mejoras de rendimiento o nuevas funciones llegarán en **series posteriores** de parches que amplíen la **aceleración**, la **gestión energética** y el resto de la pila. **¿Se confirma el nombre “Rubin” y cuándo saldrán esas GPU?** El código habla de **“next-gen GPUs”** y de un cambio a `BOOT_42` **más allá de Blackwell**. Varios analistas asocian esa referencia con la supuesta **arquitectura “Rubin”**, pero **NVIDIA no ha anunciado** públicamente detalles ni calendarios. Los parches son una **señal técnica temprana**, no un lanzamiento comercial. --- **Fuentes**: Anuncio y parches en las listas de correo del kernel (serie *“gpu: nova: add boot42 support for next-gen GPUs”* firmada por John Hubbard) y cobertura de la novedad en Phoronix; documentación de *Rust-for-Linux* sobre el proyecto Nova. vía: [phoronix](https://www.phoronix.com/news/NVIDIA-Nova-Next-Gen-Boot42)