NVIDIA has begun taking steps in a key area for the Linux ecosystem: early compatibility of its upcoming “post-Blackwell” GPUs through Nova, the new kernel graphics driver written in Rust that the company is developing openly with an upstream approach. In a patch series submitted to the kernel mailing list, the company’s engineers introduce support for a low-level but highly significant change: the transition from the historic NV_PMC_BOOT_0 to NV_PMC_BOOT_42 as the reference register to identify architecture and revisions of future chips. The direct implication is that: future generations will zero out the old BOOT_0 and will use BOOT_42 as the authoritative source of that information.
The series of patches—signed by John Hubbard—is not just a technical curiosity. As the engineer states, it’s a necessary adaptation for Nova to “claim” reliably support Turing and later architectures and, at the same time, be ready for the GPU generations following Blackwell, which industry rumors refer to under the code name Rubin. In practical terms, the change rewrites the driver’s selection logic and documents, in chronological order, how NVIDIA’s GPU boot registers have evolved and how the code should behave according to the architectural era.
What exactly is Nova, and why does it matter?
Nova is NVIDIA’s effort to leap forward in their open source presence on Linux. It is a kernel driver written in Rust, designed for GPUs with GSP (GPU System Processor) and set to become the successor to Nouveau in the mainline kernel for modern generations (starting from Turing/RTX 20 and including Ampere, Ada, and Blackwell). Its technical strategy combines two aims: security/robustness (leveraging Rust’s memory safety guarantees) and alignment with NVIDIA’s roadmap, since from Turing onwards, GSP firmware support is required for certain low-level functions.
Though still under development, Nova represents an unprecedented gamble by NVIDIA to develop critical Linux support openly: publishing patches on kernel mailing lists and incorporating upstream comments. In this context, the adoption of BOOT42 is a key detail—seemingly arcane but essential to ensure that the driver recognizes and correctly configures GPUs beyond Blackwell.
From BOOT0 to BOOT42: a key change for the next era
Until now, the NV_PMC_BOOT_0 register held information about the architecture and revision of the GPU. Nova—like any software that needs to identify the silicon—consulted that register to decide initialization paths and tables specific to each family (from NV04 to Turing/Ampere/Ada/Blackwell). The patch series from NVIDIA states that upcoming chips will no longer use BOOT_0 for this data; instead, the info will reside in NV_PMC_BOOT_42, while BOOT_0 will be set to zero.
The change is more than just address swapping: it requires simplifying and strengthening detection logic so it functions from Turing onward without relying on fragile ifs. In fact, the accompanying diff eliminates data types like Spec and Revision and trims about 33 lines of code, enhancing clarity in the GPU enumeration and initialization module. The series’ header note explains that, with this approach, Nova will be able to reliably claim support for Turing and later for “a good long time” without additional changes to this part.
Industry context: the value of early kernel support
In recent years, NVIDIA’s Linux graphics support has advanced along two lines: on one hand, the proprietary driver (binary module) provided for GeForce, Quadro, and Data Center lines; on the other, the open ecosystem (Nouveau), historically limited by lack of documentation and reliance on firmware. Nova aims to bridge that gap for modern GPUs using Rust, with GSP support and more upstream collaboration, reducing the distance between what reaches the main kernel and what users can run on mainstream distributions.
The fact that early “post-Blackwell” patches appear so soon is significant for two reasons. First, it indicates that NVIDIA’s Linux teams have enough insight into their next architecture to prepare common driver layers now. Second, it shows internal maturity: when you change the GPU’s identity source (from BOOT_0 to BOOT_42), it makes sense to adjust all code depending on that signal as early as possible to avoid “tech debt” when new silicon arrives.
What Linux users can expect (and what not yet)
It’s important to set correct expectations: these patches do not introduce functional support for Rubin nor do they magically boost performance of existing GPUs. Instead, they are infrastructure works: laying the groundwork so that when the first cards of the next generation appear, the kernel knows who they are and where to start initializations.
For end users, the immediate tangible benefits will be limited. However, for distributors, maintainers, and ecosystem developers, this change signals important progress:
- Distributions closely tracking mainline kernels will soon be able to integrate these changes and validate that detection in Turing/Ampere/Ada/Blackwell remains unaffected.
- Userspace projects (Mesa, Wayland/GBM, window managers) can anticipate name and path changes affecting udev rules, device detection, and quirks.
- Diagnostic and telemetry tools will be able to incorporate
BOOT_42data into reports for upcoming systems.
Meanwhile, the big question remains: how fast and comprehensive will the operational support of Nova be for new GPUs once they are publicly available? Historically, NVIDIA’s open support has been gradual and sometimes conservative regarding 3D acceleration, power management, and advanced features. Since Nova is born in Rust and focuses on upstream collaboration, it doesn’t guarantee miracles, but it does give better foundations for iteration.
What about Blackwell… and Rubin?
Although NVIDIA avoids publicly naming the architecture after Blackwell, code observers and specialized media interpret this “next-gen” as a reference to Rubin, the internal codenamed upcoming generation. Documentation within the patches mentions support from Turing to Blackwell relying on BOOT_0, while future generations move to BOOT_42 with BOOT_0 reset to zero. This signifies a technical marker of “beyond Blackwell.”
From a compatibility perspective, Nova’s modification aims for the driver to claim support from Turing onward, not affecting older lines (NV4x, Tesla, Fermi, Kepler, Maxwell, Pascal), where Nouveau remains the standard. In modern GSP-enabled GPUs (Turing+), the expectation is that Nova will, over time, become the reference driver in the main kernel.
Security, Rust, and cleaner code
The choice to write Nova in Rust is more than cosmetic. Kernel drivers involve risks like buffer overflows, double frees, or race conditions—any of which can lead to serious vulnerabilities. Rust’s guarantees—memory ownership, borrowing, lifetimes—help reduce entire classes of faults. The series of patches accompanying the BOOT_42 adoption removes types and simplifies detection logic, showing the team is actively addressing technical debt and setting a stable foundation for the future, avoiding the need for frequent reworking.
Impact on software development and tooling
Applications and toolchains that interact with GPUs at a low level—ranging from provisioning systems and fleet monitoring to hardware diagnostics—will need to update their logic if depending on NV_PMC_BOOT_0. In enterprise environments automating inventory and compliance checks by GPU family, it will be wise to support both BOOT0 and BOOT42 until Rubin-based hardware dominates.
Third-party projects aiming to integrate with Nova should closely follow mailing lists and repositories, as internal APIs and constant/register names are in flux to support this and other changes. The good news is all work is public, making it easier to comment, propose, and avoid surprises.
What might come next?
If NVIDIA maintains momentum, expect more patches expanding tables, initialization paths, and power management layers for the earliest samples of the next generation. Additional documentation within Nova’s codebase will likely clarify how to interpret BOOT_42, what bits specify family/revision, and what combinations distinguish architectures. Meanwhile, work on Blackwell will continue within Nova and the proprietary driver, aligned with commercial releases.
Advice for Linux users and early adopters
- Follow the mainline: if you like experimenting, compile recent kernels or use a rolling release distro to get these patches soon and test stability on Turing/Ada/Blackwell.
- Check dmesg: when booting a build with Nova updated, review detection and initialization messages to see if the code “claims” your device properly.
- Set realistic expectations: this is not a performance boost but a support foundation; full 3D support and features will improve over subsequent iterations.
- Participate: if you encounter detection issues, report with
lspci -nn, dmesg, and precise kernel versions; your input can help refine the transition.
Frequently Asked Questions
What is NV_PMC_BOOT_42 and why does it replace BOOT_0?
The NV_PMC_BOOT_42 register is a boot record that in upcoming NVIDIA GPUs will store architecture details and revision info of the chip. Historically, this was in NV_PMC_BOOT_0, but in post-Blackwell generations, BOOT_0 will be zeroed out. Nova updates its logic to read BOOT_42 instead, identifying new GPUs correctly.
How does Nova differ from Nouveau on Linux?
Nouveau is the traditional open driver for NVIDIA GPUs, integrated into the mainline kernel with broad support but limited by missing proprietary components. Nova is a new driver written in Rust, targeting GSP-enabled GPUs (Turing and later), developed openly by NVIDIA in view of the community to gradually replace Nouveau on modern hardware.
Will my current GPU be faster or more compatible soon?
Not immediately. These patches prepare the driver to recognize future GPUs and simplify detection from Turing onwards. Performance improvements and new features depend on further updates in subsequent patches, expanding acceleration and functionality.
Is the “Rubin” architecture confirmed, and when will those GPUs arrive?
The code mentions “next-gen GPUs” and a move to BOOT_42 beyond Blackwell. Analysts link this to the supposed “Rubin” architecture, but NVIDIA has not officially announced details or timelines. These patches are an early technical indicator, not a commercial product release.
Sources: Announcement and patches on kernel mailing lists (series “gpu: nova: add boot42 support for next-gen GPUs” signed by John Hubbard) and coverage by Phoronix; also, the Rust-for-Linux documentation on the Nova project.
via: phoronix