Framework publishes the real mainboard schematics for the Laptop 13 on GitHub under CC BY 4.0 — seven documents, one per CPU generation, no forum login and no “for educational purposes only” disclaimer. We pulled all seven, extracted every power net in them, and found something more useful than the schematics themselves: two completely different rail-naming dialects inside the same repository, for the same laptop.

That is the thing nobody explains when you open your first boardview. The tool is easy. The vocabulary is the hard part, and it does not belong to Intel, to AMD, or to the brand on the lid — it belongs to whoever drew the board. Learn to decode the naming grammar and a boardview stops being a picture of a PCB and starts being a wiring diagram you can follow with a probe in your hand.

What Framework actually publishes

The files live in Mainboard/ in the FrameworkComputer/Framework-Laptop-13 repository. The README carries the licence in one line: “Framework Laptop 13 © 2026 by Framework Computer Inc is licensed under CC BY 4.0.” That is a real open licence, not a community upload — which is why we use these and not the leaked board files that circulate on repair forums.

Here is what is actually inside each one. “Highest cross-reference” is the largest page number the drawings point at; “power nets” counts distinct net names matching a voltage pattern, extracted from the PDF text layer.

Document Pages Highest cross-reference Power nets Always-on Switched
11th Gen (Tiger Lake) 10 58 50 5 23
12th Gen (Alder Lake) 10 58 81 8 29
Core Ultra Series 1 9 84 67 4 18
Core Ultra Series 3 9 133 155 9 38
Ryzen 7040 Series 10 58 92 13 18
Ryzen AI 300 Series 9 84 81 7 17
Chromebook Edition 9 25 6 0 0

Five hundred and thirty-two power net names across the seven documents. And look at the last row: the Chromebook Edition reports six power nets and zero always-on rails. It is not a smaller board. It is a board that speaks a different language — which is the whole point of this article.

The naming grammar: two dialects, one laptop

Six of the seven documents name rails the way most Taiwanese ODM schematics do: a voltage, then a suffix that tells you when the rail is alive, then an optional suffix telling you what it feeds. The Chromebook Edition uses the convention you will recognise from Apple and Chrome OS reference designs instead: PP plus the voltage in millivolts, then the power zone.

What it is Six Intel/AMD documents Chromebook Edition What the name is telling you
Unregulated main bus +17.6VB, +17.6VB_BATT +17.6V Follows the battery/adapter, not a regulator. No single correct voltage.
Always-on rail +3VALW, +5VALW_A, +1.8VALW_TPM PP3300_Z1, PP5000_Z1 Present with the machine “off”. Measure these first.
Live/standby rail +3VL, +3VL_EC, +3VL_RTC PP3300_RTC_Z2, PP3300_EC_Z1 Feeds the EC and the RTC — the two things alive in a dead laptop.
Rail alive in soft-off — PP3300_S5, PP1800_SOC_S5 Named after the ACPI sleep state it survives.
Switched (system on) +3VS, +5VS, +1.8VS PP3300_..._X Only present once the power sequence completes.
Destination suffix +3VS_EDP, +3VS_CAM, +5VS_FAN, +3VS_RETIMER_0 PP3300_WLAN_X, PP5000_KB_BL The load. Dead camera, dead fan, dead backlight: start at its own rail.

To be clear about what is fact and what is inference: Framework documents the schematics, not the naming scheme. The meanings above are read off the evidence in the drawings, and the drawings are unusually good at confirming them. +3VL_RTC and +3VL_EC feed exactly the two subsystems that stay powered in a machine that looks dead. The Chromebook names a rail PP3300_S5 after the ACPI state it stays up in. And on page 2 of the Core Ultra Series 1 drawings, the enable of an AOZ1336DI regulator is driven by PM_SLP_S3# — the sleep-state signal literally switching a rail off. The suffix is not decoration; it is the power domain, and the schematic shows you the transistor that enforces it.

This is also why the Apple naming in our MacBook Air M2 power sequence teardown reads the same way once you know the rule: PP3V3_AON is always-on, PPBUS_AON is the unregulated bus. Different vendor, same grammar.

The signal glossary that works on any board

Rail names change per ODM. The handshake signals between the embedded controller and the SoC do not, because they are defined by the platform, and Intel publishes a real reference EC firmware — intel/ecfw-zephyr, Apache 2.0 — that documents each one. These are the names to search for in any boardview.

Signal What it means (Intel EC firmware documentation)
RSMRST#_PWRGD “Resume reset power good signal to the Embedded Controller hardware to indicate that main power rails on the board are stable, in response this module generates RSMRST output to PCH.”
ALL_SYS_PWRGD “The all system power good input generated from board circuitry indicates to the Embedded Controller (EC) that SoC power rails are stable.”
PCH_PWROK Generated by the EC in response to ALL_SYS_PWRGD; SYS_PWROK follows on platforms that need it.
SLP_S3# / S4# / S5# Indicate the host “is entering the specified sleep state indicated by the respective signal as defined in ACPI specification”. Also SLP_M, “sometimes referred as SLP_A”.
PM_BATLOW Indicates whether there is “a valid power source or enough battery capacity to power up the system”.
SUS_WRN / SUS_ACK Deep-sleep exit handshake: PCH sends SUS_WRN, EC acknowledges with SUS_ACK.
EC_DSx# Keeps the EC powered on or off during system deep sleep.

The firmware also gives the cold-boot order outright, and it is the order to test in: check for a power button press → check RSMRST_PWRGD → generate RSMRST# → propagate the button to the PCH → deep-sleep handshake → check PM_BATLOW → check the SLP_Sx signals → wait for ALL_SYS_PWRGD → drive PCH_PWROK → wait for platform reset. A board that stops at step three is a different repair from one that stops at step eight.

The part nobody covers: the cross-references point outside the document

In these drawings a net that leaves the page is tagged with its destination page — <39> EC_BKOFF#, <22> SOC_BKL_PWM_LS. Now compare with the table above. The Core Ultra Series 3 document is nine pages long and contains references to page 133. Series 1 and Ryzen AI 300 point at page 84; four documents point at page 58.

The published PDF is an extract — the interface sheets — of a much larger internal schematic set. That is not a complaint, it is a reading instruction: when you trace a signal to <58> and there is no page 58, the trail has not gone cold and you have not misread anything. The net simply leaves the part of the document that was published. Follow it on the board instead, or accept the boundary and work from the connector side. People waste evenings assuming they downloaded a corrupt file.

The part nobody covers: only one power state is safe to open

Everyone learns S3 and S5 as trivia. Read the actual ACPI 6.5 definitions and you find the specification was written with a service technician in mind. Three of the four global states carry the same literal sentence: “It is not safe to disassemble the machine in this state.” It appears under G0 Working, under G1 Sleeping, and under G2/S5 Soft Off.

Only G3 Mechanical Off says the opposite, and it says it in full: entering that state mechanically implies “that no electrical current is running through the circuitry and that it can be worked on without damaging the hardware or endangering service personnel”. G3 also has a footnote worth memorising — “except for the real-time clock, power consumption is zero”. That is why the RTC rail is on its own domain, and why +3VL_RTC can still read 3 V on a board you believe is dead.

In practice: a laptop that has been shut down from the OS is in G2/S5. Always-on rails are live, the EC is awake, and the standard names up top tell you exactly which nets those are. Pull the battery and the adapter before probing — the spec agrees with your instructor.

Which tool to install first

Both tools solve the same problem — cross-referencing the physical board against the logical drawing — from opposite directions. We covered what OpenBoardView does internally already; this is the workflow difference.

Decision OpenBoardView FlexBV 5
Cost Free, open source (MIT) Paid perpetual licence; free and demo tiers exist
Linking the schematic PDF External DDE bridge to a separate PDF viewer By filename: “Name the schematic PDF the same as the boardfile and FlexBV will automatically load this with the BRD without requiring any additional intervention”
How net search starts By part or pin name you type “Network searches from the search dialog or PDF search prioritise testpoints as the nucleation point for the netweb”
Repair history None — viewer only Per-board SQLite database alongside the board file
Formats BRD/BRD2/BDV/BV/FZ plus encrypted variants 15+, including GenCAD, KiCad, EasyEDA Pro, Allegro binary, Samsung CAD
Internet needed No No — “You do not need internet connectivity to use FlexBV”

The FlexBV design choice worth stealing regardless of which you run: start at a testpoint, not at a component. A testpoint is a place you can physically land a probe, which makes it the natural entry point for someone holding a meter — the same logic behind picking the right meter specs and behind letting the bench supply narrow the fault before you go component by component.

Limits and common mistakes

Four things to keep straight. First, a boardview is not a schematic: it gives you nets, pads and part outlines, not the logic. Framework’s PDFs are the opposite — schematic, no physical netlist. You want both open, which is exactly why the PDF-linking behaviour above matters.

Second, a boardview shows the network but never the order. Nothing in the file tells you RSMRST# must be stable before ALL_SYS_PWRGD means anything. Sequence comes from the platform documentation, and a rail measuring correctly says nothing about whether it came up at the right time.

Third, do not search for a vendor’s canonical signal name and conclude it is absent. Of the seven Framework documents, only the Intel ones contain a literal SLP_S3 or SLP_S4 string; the AMD sheets carry the same function under different names. The Intel firmware documentation admits this itself when it notes SLP_M is “sometimes referred as SLP_A”.

Fourth, a testpoint is not a via. A via is a plated hole moving a net between layers and is often covered in soldermask; a testpoint is an exposed pad the manufacturer put there to be touched. Boardview tools tag them differently, and probing a masked via is how you scratch a trace. If the pad you want is a chip pin instead, that is a clip problem, not a probe problem.

Sources

Schematic data in this article was extracted from “Framework Laptop 13” © 2026 by Framework Computer Inc, licensed under CC BY 4.0. Page counts, cross-reference numbers and net-name counts were derived from the published PDFs. We do not have a bench: every number here comes from the documents linked above, not from measurement.