HP ZBook Ultra G1a / EliteBook X G1a BIOS issues

hp-g1a-bios-issues.md

HP ZBook Ultra G1a / EliteBook X G1a — Complete BIOS & Hardware Issues

(Compiled from HP forums, Reddit, Level1Techs — May 7, 2026)

---

🔴 ISSUE 1: Boot Freeze (Critical)

The bug: Starting with BIOS 01.03.11 (EliteBook) / 01.04.03–01.04.05 (ZBook), the laptop freezes at the HP logo/spinning circle during boot. Circle stops spinning, nothing happens. Some units boot on second attempt, others are completely bricked.

Root cause: Audio hardware initialization timeout during POST. Per HP insider bootfail_cause: it's a "silicon lottery" — slightly faster hardware expects faster response times, and the BIOS timeout is too tight for some units. Explains why some machines are affected and others aren't.

HP force-pushed the broken BIOS as a "Critical" update via Windows Update — automatically, without consent. Multiple users report machines bricked overnight.

Affected Models

Model	Broken BIOS	Working Fallback	Fix
EliteBook X G1a	01.03.11, 01.05.00	01.02.05	01.05.01 (sp170213) ✅
ZBook Ultra G1a	01.04.03, 01.04.05	01.03.11	Pending — fix not yet merged

Workarounds

1. Network BIOS downgrade — Enter BIOS → Update via Network → downgrade step-by-step (01.04.05 → 01.04.03 → 01.03.11). Requires HP USB-C to Ethernet dongle — other brands may not be recognized by BIOS. WiFi option doesn't work.
2. CMOS drain + Win+V — Hold power button 30 sec (fans ramp up twice), then hold Win+V during boot ~15 sec. Temporary workaround to get into Windows.
3. Lock BIOS version — After downgrading, disable "Let OS update the BIOS" in BIOS settings.
4. USB media downgrade — sp165722.exe (01.03.02) available on HP FTP, but 01.03.02 causes kernel crashes for some. 01.03.11 is the "gold" fallback but only via network.
5. Secure Boot corruption — Some users found Windows CA certs unchecked after the freeze. Re-enabling got them booting.
6. BIOS 01.05.01 — Fixes EliteBook. Available at ftp.hp.com/pub/softpaq/sp170001-170500/sp170213.exe. Minor audio crackling on boot reported by some.

Linux BIOS Update Method (No Windows Needed)

• Run Windows .exe in Wine to extract firmware files
• Copy to /boot/efi/EFI/HP/DEVFW/firmware.bin
• Reboot → enter BIOS → "Update System Firmware" → select local media
• First attempt after EFI partition change may hang (fans at full speed) — power off/on, retry

---

🟠 ISSUE 2: Fan Spikes / Constant On-Off Cycling

Original bug (BIOS 01.03.00+): Fans spike to 100% RPM for a few seconds then stop, even on idle.

Partial fix (BIOS 01.04.03+): Fans no longer hit 100%, but now constant on/off cycling at low RPM — off → low rpm → off → low rpm, many times per minute. Motor clicks audible each time. Worsens fan longevity.

BIOS workaround: Set fan curve to 10/15 in BIOS to keep fans always-on at low speed. On AC, there's an explicit "always on" option. No equivalent option on battery.

C-State hypothesis (Level1Techs): HP's BIOS triggers fans when CPU exits deep C-states (C2/C3). Disabling C2/C3 with cpupower idle-set reduces spin-ups but increases power consumption.

YouTube background hack: Playing a YouTube video in Firefox in the background (even muted) keeps fans stable — power goes from 3W to 4W but the fan on/off loop doesn't trigger.

---

🟠 ISSUE 3: AiMT BIOS Setting Bricks the Laptop

In BIOS 1.04.03, enabling the AiMT setting causes a hard brick. Unknown what it does. Recovery: hold power 20 sec until caps lock blinks, boot, spam F10 to enter BIOS and disable it.

---

🟡 ISSUE 4: Third-Party Chargers / Dock Disconnects

Third-party chargers keep disconnecting and losing power at random times. HP Ultra G6 dock had similar issues — partially resolved in newer BIOS. One user confirmed updating the G6 dock firmware resolved their power delivery issues.

---

🟡 ISSUE 5: BSODs (Separate from Boot Freeze)

Daily BSODs with different error codes each time, starting from day 1. Affects 128GB models primarily. HP pulled a February BIOS that was supposed to fix this, then re-released it. Some users had to return units entirely.

---

🟡 ISSUE 6: QC / Hardware Defects

• Right fan bearing defect — noticeable grinding/clicking noise from right fan on some units, present from first boot. Replacement fans out of stock.
• Terrible assembly and QC — multiple users returned units for physical defects
• Biased toward Hynix RAM — Every user who reported the boot freeze also had Hynix RAM (not Samsung). May correlate with the "silicon lottery."

---

🟢 Power & Thermal Data

• APU idle: ~3W, total system idle ~10W (screen + 128GB RAM consume their share)
• CPU max: 70W sustained, brief 80W bursts, drops to 55W after extended load
• GPU max: 110-120W in high performance mode (echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level)
• Battery life: ~7-8 hours light work, ~5% battery per hour at minimal use
• External monitors (3x 1440p + internal): 7-15W average
• Vapour chamber cooling keeps palmrest cool; good thermal management overall
• PTM7950 thermal pad swap yields 8-10°C improvement (confirmed by multiple Level1Techs users)

---

🔵 Linux-Specific Notes

• amd_iommu=off breaks deep sleep on kernels 6.18.18+
• AC wakeup trigger causes immediate wake — fix: echo disabled > /sys/devices/platform/ACPI0003:00/power_supply/AC/power/wakeup
• System freezes for 1-2 sec on battery with kernel 6.19 (fixed in 6.19.8)
• Fans spinning during sleep (20-30% battery drain overnight) — fixed in kernel 6.19.8
• GNOME/Wayland stutters in video playback on Debian stable — KDE and Xorg work fine
• Long BIOS POST times fixed by draining battery to 0% (full charge/discharge cycle)
• Webcam driver patches progressing: amd_capture renamed to amd_isp4_capture (github.com/jtsiros/amd-isp4-camera)

---

💀 HP's Response

• Forum threads marked "Solved" prematurely
• Support offers: "reinstall Windows," "send it in"
• 2-month depot repair to replace motherboards — for a firmware issue HP caused
• HP deleted original bug report threads from their forum
• Quietly removed "Critical" tag from broken BIOS, quietly made older versions available
• No official fix for ZBook yet — only EliteBook got 01.05.01
• Users filing BBB complaints, contacting Tom's Hardware/The Register
• HP has a documented multi-year pattern: 2021 Victus F.10, 2023 TG01 Desktop, 2024 ProBook/EliteBook 01.17, 2025 EliteBook, 2026 ZBook — all identical bricking via firmware update
• 2024 ProBook incident only resolved after Tom's Hardware and The Register coverage

---

Sources

1. HP Forum: URGENT ZBook Ultra G1a BIOS 01.04.05 causing boot freeze
2. Reddit: ZBook Ultra G1a first-attempt boot freeze
3. Reddit: ZBook Ultra G1a fan spike issue
4. HP Forum: EliteBook X G1a BIOS upgrade stuck circle boot
5. Level1Techs: Arch SecureBoot Guide for Ryzen AI Max (HP G1a)

Also a good idea to disable usb device charging while off in bios. When on it keeps the 5v subsystem on causing 20% battery drop overnight. Mine was on be default I think.

Cool guide! Just a minor note:

Run Windows .exe in Wine to extract firmware files

You may run 7z x to extract the firmware files from the .exe binary. No need to run it or install wine.

I've had the Zbook Ultra G1a 395 with 64GB since 2026-01-30, so it's been 6 months. After the first RC of kernel 6.19, I stopped having hardware issues. I installed CachyOS following a Level1Techs tutorial (linked here) to enable Secure Boot, DKMS, and signing on updates.

Current issues:

1. I had to patch the Wi-Fi firmware to report the correct power (20W instead of 3W in max power mode). Everything works fine up to kernel 7.1.3, but with the 7.2 RC kernel, my Wi-Fi adapter doesn’t show up at all. Without the patch, it works but loses signal frequently. This is linux/mediatek related issue, not HP.

2. For some unknown reason, or since this laptop was originally the “Ubuntu” version, the Pluton security was disabled by default. This caused many TPM-related issues and prevented the laptop from entering deep sleep, resulting in about 7-11W power consumption during sleep. After adding some boot flags, I optimized this down to 3W (measured with a USB-C power meter). Finally, after weeks of debugging, I enabled Pluton, reducing sleep power consumption to 0-1W.

3. The laptop is not compatible with Thunderbolt 4 displays. I use a Dell U4025QW (140W PD), which disconnects randomly—sometimes stable for 2 hours, then disconnecting 4 times within 10 seconds. The journal logs indicate DP resync issues. I’ve tried disabling all power-saving features and Thunderbolt 4 in BIOS, but nothing helps. Dell blames HP; HP blames Dell. I borrowed a Dell TB4 dock: it doesn’t disconnect entirely (USB devices and ethernet remain stable), but HDMI and DisplayPort both disconnect randomly in the same way. This is very frustrating. At work, I use an older Dell U4320Q with 65W PD and DP-alt mode only, which works perfectly fine without external power (the laptop rarely uses more than 55W under normal workloads).

Lastly, I'd add that the actual power consumption from the cable is about 9–13W with the lid closed and not sleeping. With the display on at 40% brightness, I measured between 15–22W. Even light work pushes it to 35W, but I rarely exceed 55W on average. Depending on the adapter, it can go up to 133W, but that's very rare.

3. The laptop is not compatible with Thunderbolt 4 displays. I use a Dell U4025QW (140W PD), which disconnects randomly—sometimes stable for 2 hours, then disconnecting 4 times within 10 seconds. The journal logs indicate DP resync issues. I’ve tried disabling all power-saving features and Thunderbolt 4 in BIOS, but nothing helps. Dell blames HP; HP blames Dell. I borrowed a Dell TB4 dock: it doesn’t disconnect entirely (USB devices and ethernet remain stable), but HDMI and DisplayPort both disconnect randomly in the same way. This is very frustrating. At work, I use an older Dell U4320Q with 65W PD and DP-alt mode only, which works perfectly fine without external power (the laptop rarely uses more than 55W under normal workloads).

You need to use a more powerful dock that has enough budget for the laptop too. E.g. I have a HP Thunderbolt 4 Ultra G6 280w dock that works perfectly, I think the 180w version works too.

BTW if you are still on linux, I have some specific setup that I have done for my machine on another gist.

The laptop uses a 140W PD charger. The Dell display supports 140W PD and can deliver 140W because my other laptop, a Lenovo Yoga, which also supports 140W PD, works perfectly fine. Lenovo isn't Dell, so this is somewhat surprising, but it shouldn't be—if every manufacturer followed the PD 3.1 specification, it would be compatible. The TB4 dock supports only 96W for non-Dell systems, but that's not the issue. Even with the original adapter connected, nothing changes. If it were a power issue, why does the 65W non-TB4 display work perfectly fine on the balanced power plan?

I started a thread about it on freedesktop.org but that's probably dead and I have no more relevant info or successful ending so ...

[22:32:28] usb 5-1: USB disconnect, device number 10
[22:32:28] usb 5-1.4: USB disconnect, device number 11
[22:32:28] usb 5-1.4.1: USB disconnect, device number 12
[22:32:28] usb 5-1.4.1.1: USB disconnect, device number 15
[22:32:28] thunderbolt 0-0:2.1: retimer disconnected
[22:32:28] amdgpu 0000:c3:00.0: amdgpu: [drm] DMUB HPD IRQ callback: link_index=6
[22:32:28] thunderbolt 0-2:1.1: retimer disconnected
[22:32:28] thunderbolt 0-2: device disconnected
[22:32:28] pcieport 0000:01:00.0: Unable to change power state from D0 to D3hot, device inaccessible
[22:32:28] usb 6-1: USB disconnect, device number 7
[22:32:28] usb 6-1.4: USB disconnect, device number 8
[22:32:28] usb 6-1.4.1: USB disconnect, device number 9
[22:32:28] usb 6-1.4.2: USB disconnect, device number 10
[22:32:28] r8152-cfgselector 6-1.4.3: USB disconnect, device number 11
[22:32:28] usb 5-1.4.1.3: USB disconnect, device number 16
[22:32:28] usb 5-1.4.1.4: USB disconnect, device number 17
[22:32:28] usb 5-1.4.1.5: USB disconnect, device number 18
[22:32:28] usb 5-1.4.2: USB disconnect, device number 13
[22:32:28] usb 5-1.4.2.4: USB disconnect, device number 14
[22:32:32] thunderbolt 0-2: new device found, vendor=0xd4 device=0xc041
[22:32:32] thunderbolt 0-2: Dell U4025QW
[22:32:32] thunderbolt 0-0:2.1: new retimer found, vendor=0x1da0 device=0x8835
[22:32:33] thunderbolt 0-2:1.1: new retimer found, vendor=0x1da0 device=0x8835
[22:32:33] amdgpu 0000:c3:00.0: amdgpu: [drm] DMUB HPD IRQ callback: link_index=6
[22:32:33] pcieport 0000:00:01.1:   bridge window [mem 0xbc000000-0xd3ffffff]

Asus Z13 doesn't have this issue with U3225QE, which is also TB4 and the same Strix Halo base..

Adding a data point for 01.05.07 on a ZBook Ultra G1a 14, and two findings that may be new to this list.

1. 01.05.07 silently bumps the USB4® Retimer from 2.2.0.12 to 2.2.0.14. It is not mentioned in the History.txt shipped with SoftPaq sp172978 — those notes list GOP, PSP, SMU, EC, PXE ROM and TI PD, but not the retimer. It only appears in HpFirmwareUpdRec.log, under FlashConfirmPage::OnSetActive. Worth checking your own log if you are tracking what these updates actually change.

2. Downgrading below 01.05.07 is refused by the platform. I tried going back to 01.03.11 (sp163324). BIOS Rollback Policy is Unrestricted, Lock BIOS Version has to be disabled first (otherwise the button is greyed out and the log says BIOS update blocked by system BIOS setting, exit 1602), and with that done the staging succeeds — exit 3010, "Update will occur on restart". But on restart the firmware refuses it and boots straight through: 80 seconds from shutdown to desktop, BIOS unchanged. My assumption is the AMD PSP anti-rollback level, which reads 2 against a factory value of 1. 01.03.11 carries PSP FW 0.40.0.61 versus 0.40.1.65 in 01.05.07. An earlier rollback in April from 01.04.05 to 01.03.11 did work — both were inside the 0.40.0 line then.

My actual problem: since the update this machine can no longer be powered by an 85 W USB-C monitor. Under CPU load the PD contract collapses and re-negotiates every 1–2 seconds, taking the DP link down with it. Measured in Kernel-Power id 105: 0–1 transitions per day before the update, 7–25 per day after, same monitor and cable, and 24 transitions in a 45-second load test. HP's own charger is perfectly stable, and two other USB-C monitors (HP Z27u G3, Dell U2722DE) are fine as sole power source — the one that fails is the one with the smallest budget.

Anyone else seeing USB-C monitor charging get unreliable after 01.04.03 / 01.04.05 / 01.05.07, especially with a 60–90 W monitor? And did anyone get a downgrade past the PSP anti-rollback?

My update to this:

1. @tylerebowers I checked your config, but nothing helpful for my setup (CachyOS, Lemonade on Vulkan), I had my own fix for mediatek, fixed it for 7.2 and 7.3RC has the fix implemented, I get 23db TX on it.
2. @cevanloon-ux I'm running it daily for 8+ hours (mostly 10) at work on mentioned U4320Q, zero issues at all. On U4025QW I'm still getting DP disconnects.

I need to correct the statement, U4320Q has 90W PD, not 65W PD. Also I bought a better USB-C meter for a project and tried it on the laptop. On original adapter, it's 27.5V / <1A idle, so 24-26W, not 15-22W. On light work it's under 45W, on Claude Code with Qwen model running in Lemonade/Vulkan it takes 105W maximum from the original adapter. Compiling and other standard work takes maximum 95W, so 100W adapter is just fine for portability (Choetec 30x30x45mm) and as I sait multiple times, 90W PD is enough for most jobs. I really don't believe the issue in DP is caused by insufficient power.

Thunderbolt is a major factor. I'm having the most trouble with my LG 34WK95U-W (Thunderbolt 3 minimum requirement). Before the update, I was able to run without additional power since the first day I got the laptop. Since the update, disconnects until I connect an additional power supply (100W+ PD). Then it's stable.

Anecdotal, but I had some intermittent ThunderBolt display dropout (it's actually dual-link SST display), where the display would go black and all connected peripherals would disconnect.

Adding thunderbolt.clx=0 to my kernel flags seemed to help, as it prevents supported high-speed links from entering their CLx power-saving states while idle. Unsure if this would affect the actual link that charges the computer from the display, as I have my OEM charger connected most of the time, but worth a try.

You were right, and it took two settings on Windows to get what thunderbolt.clx=0 gives you on Linux.

USB selective suspend off fixed the failure under load — 24 PD transitions in a 45 s all-core test went to 0, cores at 100 %.

PSPP (PCIe Speed Power Policy) = Disabled in the HP BIOS fixed the failure at boot, which the Windows setting could not touch. Cold boot with the cable attached went from 17 display enumerations to 2. Settable without entering F10:

$i = Get-CimInstance -Namespace root\HP\InstrumentedBIOS -ClassName HP_BIOSSettingInterface
Invoke-CimMethod -InputObject $i -MethodName SetBIOSSetting -Arguments @{Name='PSPP (PCIe Speed Power Policy)'; Value='Disabled'; Password=''}

So on this platform it's two separate mechanisms — OS-side USB suspend and firmware-side PCIe speed policy — and each covers a different half. Thanks for the pointer; I'd written it off because my failure was load-correlated rather than idle-correlated, and that was the wrong call.

new BIOS out ! 01.06.02 released on 2026-09-10 yet the timestam says 2026-08-26

EC (embedded controller): 35.34.00 -> 35.36.00

The disconnects are still present for me. Currently on kernel 7.3.0RC1 which is generally very stable for me. I tried to apply tb clx=0 again, I first thought it helped as instead of full TB teardown I only had DP disconnects and the TB hub was alive.

In logs, I have a lot of restarts (or better said, switching between awake and sleep) of PCIe controller in the display itself, so I'm really starting to believe the issue is both HP and Dell. I added an udev rule to disable PCIe sleep, will see in a few days how helpful it is.

@morvy — thanks for testing 01.06.02 so quickly. Before I follow you onto it, two things.

First, a correction to my earlier post. I reported that setting PSPP (PCIe Speed Power Policy) = Disabled took a cold boot from 17 display enumerations to 2. That was a measurement artefact on my side: I read the counter before its 4-minute window had filled. The real figure for that boot was 5, and every boot since has still cycled — 5, 44, 14, 17. PSPP did not fix the boot-time failure for me.

What does hold up: disabling USB selective suspend in Windows reliably fixes the failure under load. A 90-second all-core test with the monitor as sole power source went from 24 PD transitions to 0, with cores at 100 %. It does nothing for the boot-time failure.

Second, and the reason I'm asking: I don't think we have the same hardware, and possibly not the same bug.

You and most others here seem to be on Dell monitors. Mine is an LG 34WK95U — 34", 5120×2160, Thunderbolt 3, and only 85 W of USB-C PD. So it's a tunnelled DisplayPort link rather than plain DP Alt Mode, and the smallest power budget I've measured on this machine.

On mine there are clearly two distinct failures:

1. Under load while running — PD contract collapses and re-negotiates every 1–2 seconds, screen flickers, battery drains while Windows says "plugged in". Fixed by disabling USB selective suspend.
2. At boot with the cable already attached — continuous cycling, no picture. Unplug and replug after Windows loads, and it's fine. Nothing I've tried fixes this one.

So when you say the disconnects are still present on 01.06.02 — which of those two is it for you? And which monitor, and what's its PD rating?

If yours is #2 and it survived the update, that saves me the exercise. If yours is #1, we may be chasing different things.

If anyone wants to give comparable numbers instead of impressions, this counts display re-enumerations per hour and needs no admin:

Get-WinEvent -FilterHashtable @{LogName="System";ProviderName="Microsoft-Windows-USB-USB4DeviceRouter-EventLogs";StartTime=(Get-Date).AddDays(-14)} |
  Group-Object { $_.TimeCreated.ToString("MM-dd HH") } | Sort-Object Name

One or two enumerations shortly after a boot is normal. Mine currently shows 11 of 20 boots cycling, highest count 44, on 01.05.07 with EC 35.34.00.

My plan: I'm deliberately not updating yet. At 11 in 20 this is close to a coin flip per boot, so a handful of boots either way proves nothing. I'm collecting a few more days of baseline this week, then installing 01.06.02 next week, then running the same count over a comparable number of boots. I'll post both tables side by side when I'm done, so there's an actual before/after instead of a feeling.

@cevanloon-ux I'm experiencing disconnects while normally using the laptop on U4025WQ only. This one is 140W PD. It's been about an hour since I disabled the power saving on PCIe in the display, zero transitions since and zero flashes too (knock knock?). This is a TB4 display. Due to those disconnects I was really not motivated to use that superexpensive monitor and I only used it on my old Lenovo Legion 5 Pro where I have no issues (and Lenovo doesn't have TB, supports 100W PD).

At work, where I spend at least 8 hours connected to U4320Q I have zero disconnects. Never had, since first day it was perfectly stable. This one is not TB, it's standard USB-C 90W PD with DP Alt Mode and that's why I believe it's stable. HP U32 4K (only 65W PD) is perfectly stable as well. So I only have issues when connected to TB4 display and doesn't matter what wattage or cable (tried on 100W PD TB4 and WD22TB4 dock too).

I also experienced those super slow boots you mention and they were all somehow connected to the Pluton processor, which when disabled, also prevents deep sleep as TPM is not working. I was fighting with them too, also turning off the laptop when the display was connected resulted in 5 minutes of waiting.

PS: updating to the latest BIOS did not work via USB, it went through all 8 stages very quickly and then said it's updating firmware but nothing was flashed. But when I kept the display connected with ethernet, I used the HP.com online search in the BIOS itself and that flashed on first try.

Follow-up as promised: 01.06.02 does not fix the boot-time failure here either. I said I'd post before/after tables instead of an impression, so here they are — plus a better way to test this than I was using, and one correction that matters.

@morvy — this lines up with what you're seeing, from the Windows side.

It looked random because I wasn't controlling the one thing that matters — whether the cable is attached at POST:

Cable already in when you press power → fails, essentially every time.
Cable out at POST, plugged in during the Windows loading animation → clean, every time.
Control for that and the failure is deterministic, so three boots are enough to conclude something. Worth stating which of the two you did when posting numbers.

Before / after, same condition (cable attached from the power button)

Firmware Boots tested Cycling
01.05.07 · EC 35.34.00 · retimer 2.2.0.12 7 7
01.06.02 · EC 35.36.00 · retimer 2.2.0.14 3 3

Counts within 4 minutes of POST — USB4DeviceRouter id 1 enumerations, and Kernel-Power id 105 power-source transitions, which is the one that tracks visible flickering:

01.05.07                        01.06.02
  enum  PD                        enum  PD
    14  31                          18  26
    17  22                          48  68   <- worst boot I have on record
    23  34                          17  32
    30  36
    17  32
    27  38
    44  64  (resume, not cold)
control, same machine, same day: cable plugged in during the loading animation
     4   0

No improvement, and the single worst boot in my whole dataset is after the update (I'm on Windows 11 Pro 26200)

That this reproduces identically on Windows and on your kernels is, I think, the most useful thing in this post. Different OS, different connection manager, different power-management stack, same failure on Thunderbolt displays and same absence on DP Alt Mode ones. That points at firmware rather than at either OS. It means thunderbolt.clx=0, your PCIe-power-saving change and my USB selective suspend are probably three doors into the same room: link power-state management.

Also confirming your update tip: 01.06.02 via HP.com's online search from inside the BIOS worked first time here too (F10 → Update System BIOS → network).

The retimer: flash logs lie
I posted earlier that 01.05.07 silently bumps the USB4® Retimer 2.2.0.12 → 2.2.0.14, based on HpFirmwareUpdRec.log, which does say exactly that:

Firmware update found for: USB4(R) Retimer
  Current Version Feature/Major/Minor/Build: 2 / 2 / 0 / 12
  New     Version Feature/Major/Minor/Build: 2 / 2 / 0 / 14

It never applied it. For the twelve days afterwards, across dozens of boots, HP_BIOSSetting kept reporting USB4(R) Retimer FW : 02.02.00.12. It only flipped to 02.02.00.14 after I installed 01.06.02 from inside the BIOS.

So HpFirmwareUpdRec reports success for a sub-component it didn't flash. If you're tracking what these updates actually change, read the version rather than the log:

# needs admin
Get-CimInstance -Namespace root\HP\InstrumentedBIOS -ClassName HP_BIOSSetting |
  Where-Object { $_.Name -match 'Retimer FW|Type-C Controller' } |
  ForEach-Object { '{0} : {1}' -f $_.Name, $_.Value }

And it clears the retimer as a suspect: it's demonstrably at 2.2.0.14 now and the failure is unchanged. Same for the EC, which has moved twice (35.2F.00 → 35.34.00 → 35.36.00) to no effect.

Entering the network updater for BIOS update, it offered "Rollback to 01.04.05" as the only downgrade target. This is one of the versions causing the boot freeze at the HP logo. Anyone reaching for that button as an escape from 01.05.07/01.06.02 should know what's being offered.

My last known-good, 01.03.11, is refused directly: AMD PSP FW Anti Rollback Security Level reads 2 against a factory level of 1. The step-down route described above (01.04.05 → 01.04.03 → 01.03.11) presumably still works, but both intermediate stops are freeze versions, so I'm not taking that bet.

What actually helps on Windows, measured

1. At boot: don't have the cable attached at POST. Power on without it, plug in during the loading animation. 0 PD transitions, every time. One second of patience per boot.
2. Already flickering? Unplug for at least 30 seconds, then back in. 11 seconds was too short; 31 worked.
3. Under CPU load: disable USB selective suspend. A 90-second all-core test with the monitor as sole power source went from 24 PD transitions to 0. Does nothing for the boot case.
4. Tested and useless here, so nobody has to repeat it: Pre-boot DMA Protection = Disable (3 of 3 boots still cycled), PSPP (my earlier claim about that was a measurement error, corrected above in the thread), PCIe ASPM off, Fast Startup off, and the monitor's DisplayPort version set to 1.4.

The firmware brings the Thunderbolt link up itself during POST. That's why the monitor shows the BIOS menu fine. The OS connection manager then has to take over that firmware-established link, and that handover is what breaks. With no cable at POST the firmware never touches it, the OS negotiates from scratch, and it's clean.

That fits replugging working, a short unplug not being enough, and resumes being erratic. It also fits there being no fix in setup: the full settings list on this machine (290 entries) contains no pre-boot Thunderbolt or USB4 option at all.

Glad to be told I'm wrong about the mechanism. The numbers hold either way, and anyone can generate a comparable table in one line:

Get-WinEvent -FilterHashtable @{LogName="System";ProviderName="Microsoft-Windows-USB-USB4DeviceRouter-EventLogs";StartTime=(Get-Date).AddDays(-14)} |
  Group-Object { $_.TimeCreated.ToString("MM-dd HH") } | Sort-Object Name