Se você vem acompanhando a saga do NVIDIA Nova driver — o novo driver open-source escrito em Rust — sabe que um obstáculo gigantesco sempre esteve no meio do caminho: colocar o GSP (GPU System Processor) para rodar. Hoje, uma nova série de patches mira exatamente esse calcanhar de Aquiles: ela processa e prepara os firmwares necessários para iniciar o GSP em GPUs Ampere, costurando etapas que até então estavam soltas. É o tipo de mudança que não rende “fps” amanhã de manhã, mas que muda o destino do projeto.
Por que isso importa? Em Ampere (e em gerações seguintes), a NVIDIA deslocou boa parte do bring-up e da gestão do hardware para o GSP — um microcontrolador RISC-V dentro da GPU. Sem boot de GSP não tem inicialização completa: é como ter um carro moderno… sem a ECU. A própria documentação da NVIDIA descreve o GSP como o “cérebro” que assume tarefas de inicialização e gerenciamento do GPU. Em outras palavras, ligar o GSP é o momento “luzes acesas” do stack.
O que a série faz — e por que é tão complexa
O patchset (v5) apresentado por Alexandre Courbot dá sequência direta ao trabalho que já havia criado a região WPR via FRTS, mas que ainda estava distante de um GSP executando de verdade. Agora, entram em cena dois pacotes de firmware e uma boa dose de engenharia de boot segura:
- Booter: um firmware “Heavy Secured” que roda no microcontrolador SEC2 (Falcon). Por exigência de privilégio/assinatura, é ele quem tem autoridade para carregar o próximo estágio no GSP.
- GSP bootloader + GSP firmware: o bootloader sobe no core RISC-V do GSP, verifica a imagem e então carrega o firmware do GSP propriamente dito.
Esse “baile” de firmwares não é capricho: é parte do modelo de segurança/assinatura da plataforma. O código traz parsing de cabeçalhos comuns, seleção e aplicação da assinatura correta com base em fusíveis/IDs lidos do hardware, e prepara cada blob para ser injetado nas memórias IMEM/DMEM dos Falcons com os parâmetros certos. É a etapa de confiança da cadeia de boot — se esse elo falha, nada mais anda.
O toque de Rust — e de arquitetura
Para acomodar o crescimento do fluxo de boot, o time move o processo para um método dedicado (fora do construtor da GPU), inicializa a estrutura Gpu in-place (pinned), impõe Send nas traits dos engines Falcon (para manter invariantes de driver/pci) e introduz facilidades como Chipset::name() para resolver caminhos de firmware de maneira limpa. Não é apenas feature — é faxina estrutural que tira atrito do desenvolvimento e reduz o uso de memória de host ao manter firmwares como variáveis locais até o GSP estar de pé.
Chega a hora do mapa de memória
Outro ponto cabeludo resolvido é a forma como o GSP bootloader quer enxergar o mundo: ele espera um page table “radix3” de três níveis, mapeando o GSP firmware a partir do endereço virtual zero. A série constrói essas tabelas (páginas de 4 KB, entradas de 64 bits), DMA-mapeia tudo e entrega ao bootloader exatamente o que ele precisa. Em paralelo, o driver calcula layouts de framebuffer (WPR2, heap, áreas para Booter e ELF do GSP) — porque carregar firmware não é só “jogar bytes”: é garantir que cada região esteja em endereços alinhados e tamanhos válidos para a firmware libos do GSP. É carpintaria de baixo nível, mas sem isso não tem hand-off.
Versões e bindings: por enquanto, 570.144
Para avançar, os patches adotam o pacote de firmware 570.144 (o mais recente no linux-firmware no momento em que o trabalho foi feito), com bindings gerados e uma camada de abstração para expor apenas o necessário ao restante do driver. A ideia é pragmática: usar hoje o que existe, mas migrar depois para um firmware planejado com as restrições do upstream em mente; portanto, manter suporte a múltiplas versões de firmware não é prioridade durante a fase instável do Nova.
E o que vem agora?
Pense nisso como montar uma pista de decolagem: a série prepara Booter, bootloader e imagem do GSP, posiciona tudo na memória e define a sinalização. O próximo passo é acionar a sequência para valer — rodar Booter no SEC2, injetar o bootloader RISC-V, validar a imagem e soltar o GSP. Em agosto, outra rodada de patches já havia deixado o GSP “RISC-V active”, conversando com o host — agora o terreno está bem mais nivelado para chegar ao “fully active” que libera recursos reais de inicialização e gerenciamento. Quando isso acontecer, veremos os primeiros sinais práticos de vida do NVIDIA Nova driver em Ampere (e a fundação para evoluir no user-visible).
Tradução do impacto
Para quem usa Linux no dia a dia, por enquanto isso ainda é infraestrutura. Mas é a infraestrutura que separa um experimento acadêmico de um driver que liga e funciona. A boa notícia é que essa etapa não é “a milésima otimização”: é a ponte obrigatória para que o Nova tenha controle real sobre placas Ampere — e, depois, possa subir modos de vídeo, fazer gerenciamento de energia, reset, e tudo o que transforma uma GPU moderna em dispositivo utilizável com software aberto. A fundação está sendo concretada — e em Rust.
Notas: a série tem base no drm-rust-next e depende de patches de pin-init e Alignment no Rust-for-Linux, com a árvore consolidada publicada por Courbot em um branch público — uma boa referência para acompanhar a evolução entre versões do patchset.
Resumo em uma frase: a nova série do NVIDIA Nova driver não “faz barulho” na tela ainda, mas encaixa o dominó mais difícil — o pipeline de firmwares e memória que viabiliza o boot seguro do GSP em Ampere.
Créditos: trabalho liderado por Alexandre Courbot (NVIDIA), com revisões/feedback ativo da comunidade de gráficos e do projeto Rust-for-Linux.
