New Framework Laptop 13 Pro DIY, assembled without issue. Every single boot spends 3 min 05 as a black screen before the Framework logo, then reaches the login screen in 15 seconds. I’ve spent a while narrowing this down and would like to know whether other 13 Pro owners see the same.
System: Core Ultra 5 325, Framework 32 GB LPCAMM2 (Micron MTD16C20325N4FN023F1), WD_BLACK SN7100 1 TB, BIOS 3.02, EC sakura-3.0.2-cf48815, NixOS 26.05, kernel 7.2.5.
The delay is entirely pre-OS. systemd-analyze:
Startup finished in 3min 1.902s (firmware) + 5.335s (loader) + 507ms (kernel)
+ 2.364s (initrd) + 3.486s (userspace) = 3min 13.597s
ACPI FPDT gives firmware_start_ns = 543013218, so the firmware starts executing normally and burns the 181 s internally. Nothing from the distribution can be involved - this is all before the bootloader is even loaded.
It is not memory training. The “Memory Training in Progress” screen shows up exactly where the guides say it should: first boot after assembly, first boot after reseating the LPCAMM2. It lasts about 30 seconds - and is then followed by the very same 3-minute black screen every other boot shows. Training is a short, visible, separate phase; the 181 s start once memory is already initialised.
The panel is also alive well before the logo: for roughly the first minute of the black screen the backlight is clearly on, then it switches off entirely for the remaining two minutes, then the logo appears. Display up, display down, display up again, all within the 181 s. The LED diagnostic fires at 1 min 30, just after that transition. Looks more like a platform reset mid-POST than a long continuous operation, but I can’t prove that.
Other observations:
- Warm reboot is as slow as a cold boot. Repeated cold boots give the same timing within a few seconds.
- Holding F2 from power-on never enters setup; it only registers once the logo is up. Setup is reachable only via the bootloader’s firmware entry.
- LED diagnostic sequence: white, 12 green, orange, then
10011001(blue=1, green=0) = 0x99. All twelve checks pass, including S0 and the memory check.
Ruled out, with no change in timing: all expansion cards removed; battery only vs. AC; USB4 device measured boot disabled; Quick Boot already enabled, Network Stack disabled, boot Timeout 0, Boot performance mode Turbo; LPCAMM2 removed and refitted with the interposer inspected (clean, seated on its pegs, contact marks even) and progressive tightening in the 1-3 order; mainboard reset procedure (guide 737) performed at support’s request; BIOS is 3.02, which is the only release ever published, and fwupd confirms System Firmware 0.0.3.2 as current with nothing newer on LVFS.
I have no idea what actually consumes those 181 s. The EC console ring buffer only retains about twenty seconds, so the firmware phase is overwritten before I can read it from userspace.
If you have a 13 Pro - ideally an Ultra 5 325 - could you post this?
systemd-analyze
Valerii_Myronov has since reported 6.204s of firmware on an Ultra X7 358H with the same BIOS, EC and memory module, so the firmware can clearly boot this hardware in six seconds. The CPU tier is the last uncontrolled variable between us, which is why an Ultra 5 325 data point would be the most useful thing right now.
If someone knows a way to capture the EC console or POST codes across a full boot, or what 0x99 maps to in Insyde’s table on this platform, I’m all ears.
A ticket is open with support; I’ll update this thread with whatever comes back.
Edit 19/09/2026: removed the memory speed observation. I originally flagged 6800 MT/s as a possible anomaly, based on the 7467 MT/s figure in Intel’s specs for the Ultra 5 325. Valerii_Myronov pointed out that the board listing gives 6800 MT/s for this CPU and notes the 7467 there was a listing error - so 6800 appears to be the expected speed and I’ve dropped that line. Also added the mainboard reset, and his 6.204s firmware timing on an X7 358H as a comparison point.