View source for Flashing the 300 W VBIOS

Most 8 GB cards ship with VBIOS 92.00.67.00.01, the 250 W image. On it the driver reports a GPC and memory VF-offset
range of [0 .. +0], so no undervolt can be applied, whatever a tool says it set. The factory 300 W image
92.00.6D.00.0A, which NVIDIA shipped on the same board part number (900-11001-0108-000), exposes an offset range of
[-1000 .. +1000], boots the HBM at 1728 MHz instead of 1458 MHz, raises the SM ceiling from 1410 to 1695 MHz, and
keeps a 250 W default cap (300 W is the maximum it allows). This page is the flash procedure as run on eight cards in
one night, with the numbers before and after. It does not touch the memory or compute unlock, which stays in the
driver; see [[Driver unlock]].

The 10 GB card has no 300 W image (its only VBIOS is 92.00.66.00.02); this page is for 8 GB cards. See
[[VBIOS and firmware]] for the full image inventory.

== Why flash it ==
=== The 250 W image has no undervolt lever ===
<code><nowiki>nvml_oc -i N</nowiki></code> (the helper 170tune uses) reports <code><nowiki>allowed range : [0 .. +0] MHz</nowiki></code>
for both the GPC and the memory VF offset on every 92.00.67.00.01 card. An offset call can return success and the
driver still drops it; only a readback proves it applied. On the same cards after the flash the range reads
[-1000 .. +1000].

{{Status|Proven}} {{Cards|8 GB}}<br />
{{Source|handle=mrpec|date=2026-08-01|link=https://discord.com/channels/1518634379604136178/1518695328008638516/1533150703328039085}}<br />
{{Source|handle=unmotivatedgene|date=2026-08-23|link=https://discord.com/channels/1518634379604136178/1518695328008638516/1541201873803943997}}<br />
{{Source|handle=darkmaniac7|date=2026-10-31|note=lab notes}}

=== Same board, same IDs ===
Both images carry device 10DE:20C2, subsystem 10DE:1585 and board ID 0x030A, and both have been read off cards with
board part number 900-11001-0108-000 and die 20C2-105-A1. nvflash accepts the 300 W image on a 250 W card without any
override because the IDs match; it is a signed NVIDIA image, not a modified one.

{{Status|Reported}} {{Cards|8 GB}}<br />
{{Source|handle=con3po7016|date=2026-08-23|link=https://discord.com/channels/1518634379604136178/1518692084729511967/1541194940997046322}}<br />
{{Source|handle=wakeupmbrc1|date=2026-08-30|link=https://discord.com/channels/1518634379604136178/1518695289278566450/1543658140875235459}}

== Before you start ==
# '''An 8 GB card on 92.00.67.00.01.''' Read it with <code><nowiki>nvidia-smi --query-gpu=index,pci.bus_id,vbios_version --format=csv</nowiki></code>. A card already on 92.00.6D.00.0A has nothing to gain.
# '''nvflash 5.867 for Linux''', the <code><nowiki>x64/nvflash</nowiki></code> binary from the TechPowerUp download (the zip holds x86, x64, aarch64 and ppc64 builds; the Windows zip is a different download).
# '''The ROM''', TechPowerUp VBIOS database entry 268495 (listed there as "CMP 170HX 0 MB"; the size column is wrong). Verify it before it goes near a card: see below. A copy is attached to this page.
# '''A rollback ROM.''' Save one card's 92.00.67.00.01 image with <code><nowiki>nvflash -i N --save</nowiki></code> before you write anything. The static part of the image is identical across cards of the same version, so one dump serves as the rollback for all of them.
# '''A way to power the machine off and on''' that does not depend on the GPUs: a BMC, or someone at the button. The procedure needs two cold cycles, and a wedged flash controller only clears on a cold cycle.
# '''The driver unloaded, or never loaded.''' nvflash refuses to write with the NVIDIA kernel module present. The method below boots without it, which also avoids the unbind hang described further down.

== Verify the ROM ==
The TechPowerUp file matched these values exactly:
{| class="wikitable"
! Field !! Value
|-
| Version || 92.00.6D.00.0A
|-
| Build / modification date || 06/16/21 / 04/07/22
|-
| Size || 1,044,480 bytes
|-
| Device / subsystem / board ID || 0x20C2 / 0x1585 / 0x030A
|-
| MD5 || a58aae86e72b13d50603c15653350664
|-
| SHA1 || efad37d514bb94ac345719a0c56d9cd147cddfb7
|-
| SHA256 || 789e8f8d4c70dc9eb114c9fdcef6ed2d00aedf15a1eca522519de02042818723
|}
Two checks that do not depend on a hash:
* <code><nowiki>nvflash --version 300w.rom</nowiki></code> reads the header from the file only (it does not touch a card) and must print the version, device, subsystem and board IDs above, and <code><nowiki>License Placeholder : Present</nowiki></code>.
* <code><nowiki>python3 check_rom.py 300w.rom --expect 300W</nowiki></code> (attached) checks the structural markers: the NVGI header, the 300 W power bytes <code><nowiki>E0 93 04</nowiki></code> at 0x46045, the strap tier byte 0x44 at 0x41F53 (0x66 there means a forged "64 GB" ROM that bricks the card at boot), an all-zero license region at 0xFE504, and the dual-bank mirror. The same script recognises the 250 W image (<code><nowiki>--expect 250W</nowiki></code>) for checking your rollback dump.

{{Status|Reported}} {{Cards|8 GB}}<br />
{{Source|repo=https://github.com/polyuij42-del/cmp170hx-vbios-flash}}<br />
{{Source|repo=https://github.com/Consensus-Protocol/cmp170hx}}

== The procedure (driverless boot) ==
Proven on eight cards in two rounds, 2026-10-31, on a bare-metal Ubuntu box with the cmpunlocker driver build 615.71.09,
BMC power control and the tooling attached below. Every write took about 10 seconds. Read the two rules first:

* '''One nvflash operation per card per boot.''' After a power-on, the first nvflash command that touches a card's flash controller (<code><nowiki>--check</nowiki></code>, <code><nowiki>--save</nowiki></code> or a write) works; a second one on the same card fails with <code><nowiki>Falcon In HALT or STOP state</nowiki></code> or <code><nowiki>Detecting GPU failed</nowiki></code> and nothing is written. So the rollback save comes from a card you are not writing in that boot (or from an earlier boot), and the write is the first and only thing you do to each target card. A PCIe remove and rescan of one device (<code><nowiki>echo 1 > /sys/bus/pci/devices/0000:XX:00.0/remove; echo 1 > /sys/bus/pci/rescan</nowiki></code>) re-opened the window once in the lab; do not count on it.
* '''nvflash 5.867 ignores <code><nowiki>-y</nowiki></code> and refuses piped input.''' The confirm prompt needs a real terminal. It prints the card's current and replacement version strings before the prompt, and the PCI bus only in its Results table after the operation, so the attached controller confirms on the version strings (current must be 92.00.67.00.01, replacement 92.00.6D.00.0A) and checks the bus afterwards. nvflash's <code><nowiki>-i</nowiki></code> index follows PCI bus order, the same order <code><nowiki>nvidia-smi</nowiki></code> uses with <code><nowiki>CUDA_DEVICE_ORDER=PCI_BUS_ID</nowiki></code>; the Results table confirmed <code><nowiki>-i 7</nowiki></code> = bus C2 on the lab box.

Steps:
# Stop everything that holds the GPUs (engines, miners), until <code><nowiki>lsof /dev/nvidia*</nowiki></code> shows nothing. Record every card's VBIOS version.
# Keep the driver out of the next boot: <code><nowiki>/etc/modprobe.d/zz-flash-window.conf</nowiki></code> with <code><nowiki>install nvidia /bin/false</nowiki></code> (and the same for nvidia_modeset, nvidia_drm, nvidia_uvm). Mask or disable the units that would start GPU work at boot (docker, miners, any model loader). Note what you changed.
# Cold cycle: power off, 30 seconds dark, power on. Confirm <code><nowiki>lsmod | grep nvidia</nowiki></code> is empty and that the cards are enumerated with no driver bound.
# Save the rollback ROM from a card you will not write this boot: <code><nowiki>nvflash -i N --save backup.rom</nowiki></code>, then <code><nowiki>check_rom.py backup.rom --expect 250W</nowiki></code>.
# Write each target card once: <code><nowiki>nvflash -i N 300w.rom</nowiki></code>, answer <code><nowiki>y</nowiki></code> at the prompt (or let the attached controller do it). Success looks like a progress bar to 100 %, two verification reads, and <code><nowiki>A reboot is required for the update to take effect.</nowiki></code> with exit code 0. Anything else: do not retry that card this boot.
# Remove the blacklist, restore the units, cold cycle again.
# Verify: <code><nowiki>nvidia-smi --query-gpu=index,vbios_version,memory.total,clocks.max.memory,power.default_limit,power.max_limit --format=csv</nowiki></code> should show 92.00.6D.00.0A, your unlocked memory size, 1728 MHz, 250 W default and 300 W maximum; <code><nowiki>nvml_oc -i N</nowiki></code> should show the [-1000 .. +1000] range.

The attached <code><nowiki>window.sh</nowiki></code> runs those phases (<code><nowiki>check</nowiki></code>, <code><nowiki>prep</nowiki></code>, <code><nowiki>flash</nowiki></code>, <code><nowiki>restore</nowiki></code>, <code><nowiki>verify</nowiki></code>) with the lab box's unit names and bus map; edit those before using it elsewhere.

{{Status|Proven}} {{Cards|8 GB}}<br />
{{Source|handle=darkmaniac7|date=2026-10-31|note=lab notes}}<br />
{{Source|repo=https://github.com/polyuij42-del/cmp170hx-vbios-flash}}

=== Why not unbind the driver instead ===
The repository above spent eighteen script versions on the unbind route. With any process still holding
<code><nowiki>/dev/nvidia*</nowiki></code>, <code><nowiki>echo ... > /sys/bus/pci/drivers/nvidia/unbind</nowiki></code> hangs in the driver's remove path and never
returns; on one of its two cards it hung even with zero handles open, and a <code><nowiki>reboot</nowiki></code> issued in that state stalled the
machine until someone cut the power. Booting with the modules blacklisted sidesteps all of it.

{{Status|Warning}} {{Cards|8 GB}}<br />
{{Source|repo=https://github.com/polyuij42-del/cmp170hx-vbios-flash}}

=== Others who flashed it with nvflash ===
Several owners did the same flash with stock nvflash before the lab did, on Linux and on Windows; none reported a
brick from it. The bricks reported on the server came from fuse burns, SPI strap edits and A100 cross-flashes, not from
this image.

{{Status|Reported}} {{Cards|8 GB}}<br />
{{Source|handle=c133|date=2026-08-23|link=https://discord.com/channels/1518634379604136178/1518692084729511967/1541187172588326962}}<br />
{{Source|handle=c133|date=2026-08-27|link=https://discord.com/channels/1518634379604136178/1518692084729511967/1542649519739769003}}<br />
{{Source|handle=shirogeek|date=2026-09-06|link=https://discord.com/channels/1518634379604136178/1518692084729511967/1546191972392501369}}<br />
{{Source|handle=derick2k|date=2026-09-06|link=https://discord.com/channels/1518634379604136178/1518695328008638516/1546163237186441286}}<br />
{{Source|handle=phoenixone7|date=2026-09-16|link=https://discord.com/channels/1518634379604136178/1518692084729511967/1549930400707514490}}<br />
{{Source|handle=wakeupmbrc1|date=2026-08-30|link=https://discord.com/channels/1518634379604136178/1518695289278566450/1543658182298173581}}

== Results on eight cards ==
Two of the eight (bus 41 and C1) have FBPA0 fused off (one dead HBM stack each). Both took the image and initialised
cleanly at 1728 MHz; the driver log after the flash matched the log before it line for line in shape (the unlock's
privilege-mask loop prints 54 "Booter failed" lines per card on every boot; that is normal, not damage).

{| class="wikitable"
! Card (bus) !! VBIOS after !! Memory !! Max mem clock !! Default / max cap !! Offset range !! Note
|-
| 0 (01) || 92.00.6D.00.0A || 65536 MiB || 1728 MHz || 250 / 300 W || -1000 .. +1000 ||
|-
| 1 (22) || 92.00.6D.00.0A || 65536 MiB || 1728 MHz || 250 / 300 W || -1000 .. +1000 ||
|-
| 2 (41) || 92.00.6D.00.0A || 65536 MiB || 1728 MHz || 250 / 300 W || -1000 .. +1000 || FBPA0 fused
|-
| 3 (61) || 92.00.6D.00.0A || 65536 MiB || 1728 MHz || 250 / 300 W || -1000 .. +1000 ||
|-
| 4 (81) || 92.00.6D.00.0A || 65536 MiB || 1728 MHz || 250 / 300 W || -1000 .. +1000 ||
|-
| 5 (A1) || 92.00.6D.00.0A || 65536 MiB || 1728 MHz || 250 / 300 W || -1000 .. +1000 ||
|-
| 6 (C1) || 92.00.6D.00.0A || 65536 MiB || 1728 MHz || 250 / 300 W || -1000 .. +1000 || FBPA0 fused
|-
| 7 (C2) || 92.00.6D.00.0A || 65536 MiB || 1728 MHz || 250 / 300 W || -1000 .. +1000 || first attempt aborted by the controller, window re-opened by a PCIe rescan, second write fine
|}
Zero Xids, zero ECC errors, zero RmInitAdapter failures across four cold cycles.

{{Status|Proven}} {{Cards|8 GB}}<br />
{{Source|handle=darkmaniac7|date=2026-10-31|note=lab notes}}

== What it changed ==
The load is a proof-of-work miner (pearlhash, OneZeroMiner) on all eight cards with the fan wall at 15 % and caps set
per card by a thermal governor (230 to 250 W). The rejected shares below were all "Stale share" (a share submitted after
the pool changed the job: timing, not a wrong answer); there were no invalid shares.

{| class="wikitable"
! State !! Total hashrate !! Core clock range !! Temps !! Notes
|-
| 250 W image, offset 0 || 1,455 TH/s || 1215 to 1290 MHz || 70 to 79 C || baseline, same caps
|-
| 300 W image, offset 0 || 1,459 to 1,470 TH/s || 1215 to 1290 MHz || 70 to 79 C || HBM 1728 MHz cost nothing on a compute load
|-
| 300 W image, GPC offset +100 || 1,525 TH/s || 1275 to 1365 MHz || unchanged || 20 min soak, 0 Xid
|-
| 300 W image, GPC offset +130 || 1,549 TH/s || 1290 to 1380 MHz || unchanged || 20 min soak, 0 Xid
|-
| 300 W image, GPC offset +160 || 1,564 TH/s || 1335 to 1410 MHz || unchanged || 20 min soak, 0 Xid
|-
| 300 W image, GPC offset +190 || 1,579 TH/s || 1335 to 1425 MHz || unchanged || 20 min soak, 0 Xid
|-
| 300 W image, GPC offset +220, six cards || 1,598 TH/s || 1350 to 1440 MHz || unchanged || 20 min soak, 0 Xid; two cards still parked by the false alarms
|-
| 300 W image, GPC offset +220, all eight || 1,631 TH/s || 1350 to 1440 MHz || unchanged || 09:57, after the two parked cards took +160/+190/+220 clean; +11.8 % over the morning baseline. Not a safe point: see the warning below
|}
Power draw stayed at the caps the whole time: the offset lets the core hold a higher clock at the same watts, so the
gain comes with no extra heat. Two cards were held back early by a stale share each (a rule that counted any rejected
share; it now counts only invalid ones); re-run from +160, both took every rung.

=== The miner does not qualify an offset for inference ===
{{Status|Warning}} {{Cards|8 GB}}<br />
One hour after all eight reached +220 with the miner clean, the lab ran its inference benchmark against GLM 5.3 Flash
(TP4) on cards 0 to 3. Single-stream decode measured 268 tok/s against 232 before the undervolt (+15 %), 197 against
181 at two streams; then, one minute in, card 0 (the hottest slot, 77 to 79 C under the miner) began flooding
<code><nowiki>Xid 48</nowiki></code> (uncorrectable ECC error in GPC3 GCC) and <code><nowiki>Xid 172</nowiki></code>
(uncorrectable SRAM error in GPC 3), 97,000 lines in five minutes, and the engine died. That is the same pair the
Discord reports for a too-deep offset. At the same time card 5, which only ever ran the miner, was found in "GPU
requires reset" with no Xid at all, about two hours into +220. Lowering the offset does not clear either state: card 0
recovered with <code><nowiki>nvidia-smi -r</nowiki></code>, card 5 needed a cold cycle. What this means:
* A 20-minute miner soak proves nothing about inference, and not much about a two-hour miner run either. Qualify each
  card against the engine that will serve on it, with a benchmark as the workload rung, and soak for hours, not minutes.
* Hot-slot cards have the least margin. Expect them to land well below the cool ones.
* +220 is not a safe point on this box. The lab reverted every card to 0 and will re-ladder with inference gating from
  +100 in 30 MHz steps.

{{Source|handle=darkmaniac7|date=2026-10-31|note=lab notes}}<br />
{{Source|handle=ichundes|date=2026-10-07|link=https://discord.com/channels/1518634379604136178/1518695289278566450/1557350219111342183}}

{{Status|Proven}} {{Cards|8 GB}}<br />
{{Source|handle=darkmaniac7|date=2026-10-31|note=lab notes}}

== Risks and what the community saw ==
* {{Status|Warning}} One owner advised against the 300 W image because a photo of a burned 170HX had been posted earlier and the board lacks some power-delivery parts of the full layout. The photo is not in the exported history and no post ties a burned card to this image. The image's own default is 250 W; nothing on the lab box sets 300 W, and the undervolt reduces current at a given cap rather than raising it. Keep your cap at or below 250 W until you have a reason and the cooling to go higher. {{Source|handle=xanthefin|date=2026-10-18|link=https://discord.com/channels/1518634379604136178/1518692084729511967/1561336153515364444}}
* {{Status|Contested}} HBM at 1728 MHz: one owner on the 300 W image with a 250 W limit passed GPU-burn with no errors but saw sporadic Vulkan memtest errors across the HBM dies; the eight lab cards (Hynix) ran clean. If a card misbehaves at 1728 MHz, 170tune can set the memory clock back down (not on FBPA0-fused cards, where the PLL tool must not write). {{Source|handle=cute_sc2|date=2026-08-08|link=https://discord.com/channels/1518634379604136178/1518692084729511967/1535648815456198667}}<br />{{Source|handle=darkmaniac7|date=2026-10-31|note=lab notes}}
* {{Status|Warning}} A failed flash is recoverable only with an SPI programmer with a 1.8 V adapter (the flash IC is 1.8 V; some "3.3 V" CH341A units put out 5 V, so a CH347 unit whose software selects the voltage is the safer buy). Power loss during the write and the wrong file are the two real ways to get there; both are yours to prevent. {{Source|repo=https://github.com/Consensus-Protocol/cmp170hx}}

== Rollback ==
The same procedure with your saved 92.00.67.00.01 dump as the image: one write per card in a driverless boot, then a
cold cycle. The lab keeps its dump with the rest of the evidence; any card's dump of the same version works for any
card of the same version.

== Files ==
* {{Download|file=CMP170HX_92.00.6D.00.0A.rom|compact=yes}} The 300 W image, byte-identical to TechPowerUp 268495 (hashes above).
* {{Download|file=Vbios_check_rom.py|compact=yes}} Structural ROM check (MIT, from polyuij42-del/cmp170hx-vbios-flash).
* {{Download|file=Vbios_flash_one.py|compact=yes}} The pty controller that answers nvflash's prompt only after it has echoed the expected versions, and checks the bus afterwards.
* {{Download|file=Vbios_window.sh.gz|compact=yes}} The lab's phase script (gzipped: the wiki refuses a shebang script under a plain extension) (check, prep, flash, restore, verify); unit names and bus map are the lab box's.

== Related ==
[[VBIOS and firmware]], [[Undervolting and power limits]], [[Driver unlock]], [[170tune]], [[Troubleshooting]].

{{ImportFooter}}
[[Category:Unlocks]]
[[Category:8 GB]]
[[Category:Cooling and power]]