The DGX Spark firmware stack

Accelerated Computing DGX Spark / GB10 User Forum DGX Spark / GB10
1

Following up on @emihuang’s boot-chain question: I’ve spent some time mapping what firmware the Spark actually runs, how each piece is updated, and where the signature checks live, since that determines what a custom-firmware could and couldn’t do. Everything below comes from the box itself (fwupdmgr), the public LVFS catalog, the public LVFS capsules, and public Microchip documentation.

The firmware inventory

NVIDIA publishes five firmware components for the Spark on LVFS (the service fwupdmgr uses). All five arrive as UEFI capsules and are marked signed:

LVFS component What it is Version on my box
…socfw.firmware SoC firmware — UEFI, GPU initialization, and the TrustZone secure partition that mediates power/thermal/EC access 2.155.11
…ec.firmware Embedded controller — power sequencing, power/thermal budget tables, fan control, RTC, USB-C PD policy 3.5.8
…ec.nofuse.firmware The same EC firmware built for EC parts without security fuses not matched on this unit
…tpm.firmware Trusted Platform Module 0x7020401
…usbpd2.firmware USB-C Power Delivery controller (the EC manages it over I2C) 0x516

(Dotted versions are as in NVIDIA’s release notes; the others are shown as fwupd reports them. The TPM component is in the catalog but doesn’t appear as a device on my unit; the others all show up in fwupdmgr get-devices.)

Alongside those, the box carries firmware that updates outside LVFS:

  • ConnectX-7 NIC firmware (28.45.4028) — updated via devlink/fwupd, Mellanox/NVIDIA-signed.
  • NVMe SSD firmware (Samsung MZALC4T0HBL1) — Samsung vendor channel.
  • UEFI Secure Boot key databases — NVIDIA platform key, Microsoft KEK/db CAs, dbx revocations — also maintained through fwupd.
  • Two boot ROMs that never update: the SoC’s boot ROM and the EC’s boot ROM are immutable code in silicon.

How it boots

Two independent chains:

SoC chain: immutable boot ROM → NVIDIA-signed early boot and SoC firmware (the socfw capsule: UEFI, GPU init, and the secure partition) → DGX OS. Linux talks to the secure partition over FF-A (the nvidia-ffa-ec driver); the partition translates host requests into eSPI traffic toward the EC.

EC chain: the EC is a Microchip MEC172x (MEC1723-class) on the SoC’s eSPI bus. Its 128 KB boot ROM runs first and authenticates (and can decrypt) the application image before executing it. The application is a Zephyr RTOS build — I pinned it to Zephyr v3.7.0 from commit-dated code markers in the distributed capsule; the stack is Zephyr + MCUboot + picolibc (all Apache-2.0), with NVIDIA’s application layer closed.

How updates flow, and where the locks are

fwupd downloads a signed cabinet from LVFS, stages the capsule on the EFI system partition, and at the next boot the UEFI validates the capsule’s PKCS#7 signature and dispatches it through the ESRT entry to the target device. Three independent checks matter for anyone thinking about custom images:

  1. fwupd’s cabinet signature — host-side, so an administrator can substitute it, but that only reaches the next gate.
  2. UEFI capsule verification — the capsule must chain to a certificate in the platform database. Secure Boot is enabled, the platform key is NVIDIA’s, and the UEFI itself is NVIDIA-signed, so neither the capsule nor the checker can be swapped from the OS side.
  3. Target-side verification — for the EC, the boot ROM re-verifies the application image using key material in one-time-programmable fuses before executing it. That’s the distinction between the two EC entries in the catalog: ec.firmware for parts with fuses programmed, ec.nofuse.firmware for parts without. My unit reports the fused component’s GUID, as production units do; the nofuse build is presumably for engineering units. The EC’s firmware also lives in the chip’s internal flash, and SWD/JTAG debug is locked on fused parts.

The overall shape: every field-updatable firmware on the box is verified by a signature chain rooted in keys NVIDIA or the silicon vendor holds, with the final root in immutable ROM. Microchip documents the MEC172x family’s boot ROM authentication and markets it as a hardware platform root of trust (NIST SP 800-193); their public errata describes the ROM retrying image authentication up to 15 times on failure.

What this means for custom firmware

  • EC: the application layer is closed, production parts are fused, and the flash is internal to the chip. Building a replacement is conceivable — the RTOS and the MEC172x SoC support are in upstream Zephyr — but loading one on a production unit would require an unfused part, and a replacement would also have to reproduce NVIDIA’s host-facing protocol bit-exactly (the eSPI window map, mailbox opcodes, boot handshake, power sequencing), because the SoC side cannot be modified to adapt to it. Unfused MEC172x development hardware does exist: Microchip’s mec172xevb_assy6906 and Antmicro’s open-source MEC1723 eSPI debugger board.
  • SoC firmware / UEFI: capsules are NVIDIA-signed and verified against the platform database, and the chain roots in the SoC’s boot ROM.
  • NIC / SSD: vendor-signed images through vendor tooling.
2

The Spark is unusually well-positioned for Nvidia to consider offering options here.

NVIDIA ships unlockable Jetson dev kits, publishes BMC sources on its bigger DGX boxes, and markets the Spark as the open AI machine. “Publish the EC application sources” is a request with real precedent at NVIDIA specifically.