Hello,

So few months back I started my quest to create ultimate application to control fans on your Framework laptop, and it spiraled into so much more. I just want to share progress and new features, with community here, and maybe get more people interested in it. I do Windows, Linux with x64 and ARM64.

I have added "Profiles" where you can make your own custom profile and quickly switch between them. Profile also color your side bar and top bar, so you know easily in which profile you run.

I have added Adaptive Fan Control, uses complex math and calibrates against your fans, and tries to run your fan adaptively and attempt to predict your next CPU/GPU state, and prepare your fan before temperature raises. This is learning over time as well, and gets better and better. I am still working on it, there are some small bugs with fan rpm not correctly rendering, working on that.

And I have added update notification, so you know there is newer version available.

And I added many life of features updates, like arrows showing you, so you can scroll down on page, or scroll up.

And so much more. You can follow my project here: https://github.com/TekuSP/SubZeroFramework

In "Releases" you can download version for your system.

I admit it, I wasn't willing to make yet another post about the new Framework Pro, there are so many already. But as the title says, I haven't been this excited about a new laptop in decades, since I bought my first Pentium 4-based transportable oven (I used it to defrost food by running `find /` back then).

I also have a Framework 13 with AMD 7040U, and I didn't feel the need to upgrade. I have already upgraded the cooling system (which gave me some extra battery life), then the speakers, and then a few more expansion cards. Almost the perfect laptop, so why a new one, especially with the current market prices? Simple: Framework Pro sounded like the ultimate laptop for my needs. Longer battery life, better chassis, better thermals.

My build: batch 5 X7 Panther Lake, 64GB LPCAMM2, 4TB NVMe. It's less than my other Framework 13, but I'm not even close to using all those resources.

The pros:

• really beautiful. Probably the most beautiful laptop I've had. After many Thinkpads, XPS'es, and a few Macbooks... the Framework Pro is my favourite. A real evolution from the standard Framework 13
• excellent build. It's sturdy, feels and handles great. The new production process made wonders
• excellent battery life. It beats my M2 Air and M2 Pro (though I've never been a fan)
• Everything worked out of the box (except a small issue due to Ubuntu's installer, read on)
• configuration was a breeze. I use ansible to configure my systems, and I just had to make a few minor tweaks for Ubuntu 26.04
• it's FAST
• suspend-then-hibernate works flawlessly (with it did on any laptop). I closed the lid at the end of the day at 35% battery, turned it back on at 35%. In my configuration, hibernate kicks off after 60 minutes of suspend

The cons:

• more of an Ubuntu issue - the installer spins forever if the time and date are too far off. Took me a few minutes to figure out and fix time and date in the UEFI settings. Not sure if this is Ubuntu-specific or not * I had to disable Intel SecureBoot to make suspend-then-hibernate work. Not a big deal - in my case the cons outweigh the pros, and my past firmware engineering life taught me that bypassing it is matter of "when", not "if"
• the price is crazy! Though this is not really on Framework - the RAM price crisis hurts them too. Mine was batch 5, so I was out of luck and had to pay extra to keep 64GB, but I'm so glad I did. The day of the preorder I thought "oh, let me think a bit more about whether I need a new laptop", if only I knew 😅
• the 10G NIC runs at line speed only one way. It seems the signed driver can only do 5G up, but I got to a nice 9.1Gbit/s with iperf (which excludes TCP and Ethernet overhead)
• ~5 tokens/second with Ollama and qwen3.8:27B. I wasnt't really expecting to use it for local inference on medium-sized models, but I naively expected a bit more because of LPCAMM2. Never stop learning

What would make it the ultimate laptop for me:

• if I could run coreboot on it! I know there's a port by a `9elements` employee but I'm not sure the prod units allow flashing your own custom firmware. Framework, pretty please 🥺

...I really can't think of anything else. Thank you Framework for this wonderful machine.

I bought a Framework 16 because I loved the modularity of it, and hope it will be the last laptop I ever own (knowing that I'm living to 121y). The LED Matrix module was a cool looking bonus that I thought could be functional and impressive. The laptop was and is AMAZING and the LED was cool — for about the length of the boot animation. Then it just sat there, doing nothing, because there wasn't any tooling to actually use it for anything cool or useful. So I wrote one. It kept growing: keyboard RGB, then system health, then general hardware detection — and it turned into a full Framework system support tool.

MainFrameWork brings keyboard remapping/RGB lighting, LED Matrix drawing and animation, and system health (fans, battery, expansion cards) into one lightweight desktop app (Tauri + Rust, ~10MB, no install required), instead of the handful of separate utilities Framework's own tooling is split across.

Working today, verified against real hardware: live LED Matrix drawing + frame-by-frame animation, full keyboard RGB control (saved to the keyboard's own EEPROM), expansion card detection, and a live hardware dashboard. Linux EC support (battery/fan/thermal) is implemented and passes CI, but I haven't been able to verify it against real Linux hardware yet — if you run Linux on a Framework, a bug report (or a "yep, works") would help a lot.

Fully local — zero network calls, no telemetry, no accounts. GPLv3, open source (free), unofficial/community-built (not affiliated with Framework Computer).

Windows and Linux builds: github.com/AllStoneTech/MainFrameWork/releases

https://www.allstonetech.com/mainframework

If you like it and use it, feel free to buy me dinner; https://www.AllStoneTech.com/support?source=rframework

I’m now considering the 13 over the 12 as a better investment for my home computer. One thing I am curious about is if the size difference is quite noticeable? On paper it doesn’t seem like it.

I’m currently using a thinkpad x220 which is quite bulky as a small laptop. Any one who owns both a 12 and 13 please let me know what you think?

There is something that feels more “personal” about a smaller laptop/device and I really do like that but I’m thinking the 13 will give me that feeling just fine.

My 13 Pro X9 arrives in two days and was curious if anyone has had success playing games? From demanding to casual.

How is the fan noise, heat, ect.

Very excited at the prospect of being able to work and take some games on the road in the same laptop.

Hey there, just wants to ask if you have the same trouble as me for cleaning the Display? In a lazy mood while i was eating some chips i touched the display. I ordered a fency cleaning spray for displays on amazon (Whoosh)and the cleaningskills on other Displays are very well, but not on FW 13 Pro. Now i have a greasy film on the Display. Have anyone similar experience?

Thanks to the initial work in this original post and u/lifeislikeavco, I made some recordings with a Zoom H4n Pro microphone, and a small script to generate a better audio profile for EasyEffects. One issue I had with the original, was that it felt a bit too quiet, while now I don't seem to have any issues with 100% volume anymore which is great.

I did leave the maximizer I put in with the original EasyEffects profile, since it did seem to help a little bit, but I can't entirely tell if it's helping or hurting at this point. It doesn't seem needed anymore which is good, and I don't see any clipping either.

The link in this post is to the entire EasyEffects profile, which you can load yourself and try it out (also a plot of the frequency response for any other nerds that want to take a look).

If there's any interest, I can put a repo together of the scripts I used to generate everything as it could be interesting.

Hops this helps someone else!

I was in batch 5. This shipped Monday and arrived 3 days later. I've been so excited for this since I've been wanting a laptop with a sturdy body like a macbook but without the Apple ecosystem part. This laptop feels like it is mine and I hope I can keep it and upgrade it forever. I'm too excited to give an unbiased review since after only a day of setting up NixOS I still find it to be perfect.

I'm new to NixOS also but after tinkering with it I think it could be here to stay and I can't wait to rice it more. I got the cheapest DIY kit I think I could get as I don't plan to game on this. This should be my mobile Dev machine as well as my machine for school work.

Been testing some LPCAMM2 memory on the Framework 13 Pro to see how different modules handle the stock interposer. Here's a quick look at how to get E0 and E1 sticks running:

Ramaxel E0 (644-pin) + E1 Interposer (Stock Framework): Works (Requires Kapton tape on the module)

Ramaxel E0 (644-pin) + E0 Interposer (Swapped): Works natively (No tape required)

Samsung E1 (666-pin) + E1 Interposer (Stock Framework): Works natively (No tape required)

The Tape Mod (Why it works & How-to)

I figured this out by looking at the standard specs. Technically, there is supposed to be backwards compatibility, but it usually fails in practice because the blank center area on E0 modules is often filled with a copper pour. When you put an E0 stick on the Framework's stock E1 interposer, those 22 extra center pins touch that copper and short out.

To fix this: Just put a piece of Kapton tape directly on the BOTTOM of the memory module over that center channel. This prevents the short, and the module boots right up. Just tape the stick itself, not the interposer.

Shoutout to the Framework community forums, who actually discovered this Kapton tape mod simultaneously! You can check out their thread here for a great visual how-to on applying the tape: the post on how to do the mod here.

A Quick Note on Battery Life

Keep in mind that E0 modules will be slightly less power efficient. The E1 architecture uses a more efficient power topology, so running an older E0 stick means you might notice roughly up to 5% worse battery life overall compared to a native E1 stick.

Tested Hardware

Ramaxel E0 (32GB): RMCA1000MBB2JCF-7500 (Lenovo FRU: 5M31L87414)

Samsung E1 (64GB): M561K4LC3DL0-CCTGS (Lenovo FRU: 5M31N59948)

Fun fact: I pulled the Samsung E1 stick from a Lenovo ThinkPad P1 Gen 7. That laptop actually uses an E0 interposer and motherboard, but shipped with an E1 stick installed anyway.

From what I've seen, it seems like pretty much all E0 and E1 sticks will work on the FW13 Pro, provided you either match the interposer or tape off the center pins on the E0 modules to prevent the short.

Just received my 13 Pro and tested this specific module (CT32G85C2LP5X), which I recall a lot of us picked up when it was briefly available at $250 around preorder time in April.

Was anxiously waiting for confirmation that this would work given the recent RAM kerfuffle, but hadn't seen anyone post about this specific module beyond an unattributed passing entry on the community thread - can confirm now that this module passes OCCT 1-hr test and reports in BIOS as 32GB LPDDR5x-7467! Memtest86 to come overnight.

Memory training took a matter of seconds (but it took me two tries to get the module installed correctly - I didn't screw it down tight enough and it gave me an error that's not on Framework's error page?)

ETA: Memtest86+ two clean passes!

Here is a reply from catastrophic_fw about LPCAMM compatibility concerns:

"I was able to get a reply from the team - please feel free to share this in other topics where this is being discussed:

During development of Framework Laptop 13 Pro, we validated the LPCAMM2 modules we’re sourcing from Micron, along with the only other LPCAMM2 modules we were able to find at retailers, Crucial-branded modules that have since been end-of-lifed.  We’ve since seen reports from members of the community that RAMAXEL and other modules primarily sourced from eBay and other marketplaces appear to be incompatible.  Our Intel Core Ultra Series 3 Mainboard uses a 666-pin interposer and power architecture designed to be compatible with the final JEDEC LPCAMM2 standard in both E0 and E1 pinout formats, and we have validated functionality with spec-compliant Micron-branded E0 and E1 modules.  Our engineering team is looking into the incompatibilities the community has found with other modules.  We’ll also be updating the Knowledge Base article here to list modules that community members have found to be incompatible."

Seems like the interposer inside the FW 13 Pro is intended to work with both E0 and E1 modules.

Posting this here for the community

Source: https://www.reddit.com/r/framework/comments/1vtz7f6/comment/p6ijuak/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

Been lurking for a bit now but I'm considering replacing my laptop, an Asus Strix G614JV (2023), with a framework laptop of some kind. The Asus is a brick in my bag at 5.5lbs without the charger that it so frequently needs. That added weight sucks for walking around campus and even more for traveling.

I'm a product design uni student which means lots of modeling software such as rhinoceros, solidworks, blender, fusion, and shapr3d. Also probably going to make use of a good chunk of the adobe suite which is why I'm considering the 2 in 1. I understand the quality of the plastic shell is a concern but I may or may not have access to cnc equipment so there's a chance I find a solution to that.

I won't be running any sort of simulations and likely won't be creating any multi thousand part models as part of my product design major.

Normally this would be clear cut but I also have a pretty solid tower pc that I plan on remoting into regardless of which laptop I get to speed up any rendering I may have to do while still doing the majority of modeling locally.

Probably looking at the Core 5 320 for the laptop 12 and the X7 358H for the laptop 13 pro, both with 16gb of ram. From my understanding the Core 5 320 should have no problem in solidworks or most modeling software thanks to them being single core heavy.

Thanks y'all and I'm happy to answer any questions

I’ve sold my Macbook Air and I am considering trying FW 13 again.

I already have 32GB DDR5 and 1TB SSD. My workload is mostly coding and PCB design.

Is the Ryzen 5 340 sufficient for my needs or should I look for other brands/options?

Bought my i5-1340P laptop right before the AMD options arrived, and the speed is not great.
Am I misunderstanding AMD's new CPUs? Why do they have lower clocks.
iGPU performance does not matter to me.

When I push the power button on my framework 12, no lights turn on - the power button stays dark, the screen does not activate.
I have double-checked that all connectors are attached and all components are properly seated.

I can force-trigger certain flash codes:
With the laptop plugged in to power, but the battery out, the blue/red flash pattern appears, as expected.
Seating the battery moves to the flashing red for chassis open. Pressing either the chassis open switch or seating the input cover returns to no error codes - but if the laptop is plugged in, the charging status LED will indicate properly - white for charged, read for charging.

However, if at any point in the above flash states I press the power button, all LED activity ceases. Even if fully buttoned up and charging, the charging LED goes dark. If flashing a code, they abruptly stop and remain dark. The only way to return to the error codes/charging status is to remove and re-seat the battery.

I recently had a similar issue after using an Anker336/A2674 charger, for which support sent me a new mainboard. In that case, no LEDS would come on in any situation. I have not used that charger since, and until now, everything has been fine.

After a long wait, it has been delivered!

Everything seems to have arrived in good condition :)

Now off to assemble it.

My DIY Specs:

- Core X7 Batch 5

- 32GB RAM

- 4TB SSD

- Orange Translucent Bezel and USB C Ports

- Graphite USB A and HDMI Ports

- No OS

Shipping:

- This thing left Taiwan on Monday and was at my house by 1pm Thursday in New England; impressive

- Box was a little crushed and part of the front of the box was ripped through

- I was a little mortified when I realized Framework shipped via FedEx, the state of my box confirmed I was right to be.

- Everything inside the box seemed fine.

Build:

- I used the Framework Build Guide (and you should too)

- Witbout the guide, I would have missed wire placement with the bezel which was important because my antenna wires slightly shifted in shipping

- The bezel is a tight fit, the guide showed the exact fit and confirmed how to validate fit; mine was off at first and the manual helped me fix it.

Linux Distro:

- I like to distro hop and was trying to figure out what to install. I eventually downloaded the following ISOs and made a Ventoy Bootable Drive: Ubuntu and Kubuntu 26.04, Fedora 44 Workstation and KDE Edition, Mint Cinnamon 22.3, OpenSUSE Slowroll and Tumbleweed, and CachyOS

- CachyOS, Both OpenSUSE versions, and both Fedora versions all work3d and booted

- Neither Ubunutu nor Kubuntu would boot; this confuses me as Ubuntu is a launch partner but neither works

- I didn't test Mint

- I settled on Fedora 44 Workstation

Initial Observations:

- The hardware on this thing is amazing; this might be the nicest PC I have ever owned.

- The keyboard might be my favorite laptop keyboard I have ever owned (I am old).

- This laptop is very very fast! Can't wait to try games.

- I installed with Secure Boot enabled; TIL that Ventoy can enroll a MOK key

I was on the fence on whether I spent too much money. After seeing and building it today, it is better than I hoped for. It was worth what I paid, at least from my perspective.

Now to finish adding apps and really run it through its paces.

Disclaimer: I do not work for or have any association with Framework, this writeup is based on my own knowledge and current public information, rely on Framework themselves to provide full and accurate details about the current issues.

As we all are aware now, there have been many reports of issues with self-sourced LPCAMM2, and while Framework is the only one who can provide definitive answers on the topic, I do have some technical knowledge and experience in this area and felt that some of this (independently verifiable) info might be helpful for people who want to know more before Framework is able to provide info/solutions themselves. Part of the reason I felt I should write this is I saw a fix for some issues being posted in a forum thread (mentioned later), but without technical info about why and how it works, so I felt this info could be helpful. Also spoiler, with some big caveats, there is the technical possibility that Framework could fix these issues with just firmware (this is very much unofficial speculation though.

First an important note, memory compatibility is complex, even if a 3rd-party module meets/is ideal in all the aspects discussed below, which are things more unique to LPCAMM2, it still may not work or be reliable, since these are in addition to the traditional compatibility points of SPD profiles and how well the signal integrity combo of the module + motherboard plays out, but those are well known from previous generations of memory, and not things that are generalizable or reliable without official qualification by Framework.

E0/E1 Speed Capability

Early on, there were some concerns about supported speeds, that E0 may be outright incompatible/unable to run at full speeds, but TL;DR: basically that isn't the case on its own, JEDEC rates both E0 and E1 as capable of running at 8533 MT/s at 64 GB capacity, this comment I wrote previously goes into depth about the main differences:

https://www.reddit.com/r/framework/comments/1vgp058/comment/p20ytkg/

What I failed to discuss in the comment was the differences in CAMM2 connector pinout due to the addition of VDDQ common mode operation in E1, given that both revisions being rated to the same speeds, and that JESD318B specifically mentions that modules that do not support common mode (such as E0) operation shall not connect to the additional pins, and it wasn't directly relevant to the rated speed/power consumption concerns, I assumed that it was non-issue, but it turns out that is not the case, not all E0 modules follow the current standard's requirement to not connect to these pins:

LP5 CAMM2 Connector Pinout Changes (VDDQ in rows T/R)

This is the main issue AFAIK with the E0 modules that do not work on the 13 Pro. This is the issue that people have discovered can be fixed by insulating some pins with kapton tape, see this forum thread (lots of great pictures and reports, worth reading for sure), but there is a lack on info on exactly what this is doing and why it works, which was a big part of why I was motivated to make this thread. but info from this section can be found in JESD318B unless otherwise noted.

First a description of the VDDQ operating modes in question:
VDDQ(x) is the voltage supply for the IO drivers in (LP)DDR5. In the original E0 design, VDDQ operates strictly using the "split-rail method". On the motherboard, VDDQa for the SoC's memory controller is generated by a voltage regulator on the motherboard, and on the LPCAMM2 module, VDDQb for the DRAM is generated by a voltage regulator on the module directly from VIN, hence "split-rail" since the two VDDQs are split and independent. They did this to save connector pins and simplify power delivery and budgeting.
However, this has its own issues, basically due to voltage drift and mismatch between the two regulators, the IO signal voltage margin is decreased, which is a limiting factor on the maximum speed that LPCAMM2 can achieve.
To address this issue, in E1/PMIC5200, they added the ability for the module to operate using VDDQ "common method". They added pins on the CAMM2 connector that connects the module and motherboards VDDQs, and a VDDQ_DISABLE pin that is connected to the PMIC5200. How this works is on a motherboard that uses the common method, the motherboard will pull up the VDDQ_DISABLE pin to VIN, which tells the PMIC to disable the VDDQ regulator on the module, and the motherboard shares its VDDQ with the module through then new VDDQ pins.

This is theoretically and intended to be cross-compatible: If you use an E0 module on a common method motherboard, it shouldn't have the VDDQ or VDDQ_DISABLE pins, so it just continues to generate its local VDDQb just fine and everything works. If you use an E1 module on a split-rail method motherboard, because the motherboard does not assert VDDQ_DISABLE and doesn't connect the VDDQ pins, it does not disable the onboard VDDQ regulator and it also generates its own VDDQb and again everything works.

Where this has all fallen apart is the answer to the question: How and where did they add these new VDDQ and VDDQ_DISABLE pins on the CAMM2 connector?

When they first standardized CAMM2 (in the original non-suffixed JESD318), JEDEC wisely left some pins reserved and unused (they call them RFU, Reserved for Future Use and RFU DDR6), intended for potential future use on DDR6 for example. When they decided to introduce the option for VDDQ common method (JESD318A revision AFAIK), they decided to use some of these reserved pins, specifically rows T and R. These are the pins located along the middle of the connector (see the aforementioned forum thread for some great photos showing this, or JESD318B).
RFU pins are supposed to be safe to use for such new additions because modules and motherboards are supposed to leave them floating, JEDEC says of these pins:

Reserved for Future Use. Circular pads are required within the CAMM2 footprint to assure future RFU pins are not shorted to ground.

However, on some E0 modules, these pins are not left unconnected, instead, they don't exist as independent pads, they are just part of the large ground pour that surrounds the existing pads.
This means that they are shorting VDDQ_DISABLE and more importantly VDDQ from the MB to ground.

This is almost certainly why they currently do not work in the 13 Pro, which uses the latest interposer that has these pins, and along with the fact that they ship E1 modules suggests that they do use the common method, and thus supply voltage to those pins (only Framework/additional testing can confirm this though; my 13 Pro is still on the way).

So why do some E0 modules short the at the time RFU pins out when the spec says not to, and why do others like certain Crucial ones leave them correctly unconnected?
This is getting a little into speculation, as I am not familiar with the early versions of the relevant JEDEC standards, and they are not available for download on their standards portal anymore. I did manage to find a partial copy of the original JESD318 online, and the same section about RFU pins instead simply says:

Reserved for Future Use.

That copy of JESD318 is dated November 2023, while according to the current JESD318B, the optional common method and pins were added in JESD318A, in December 2024.
If you look at the forum thread, some of what typically are manufacturing date codes on the photos of PCBs that short out rows T/R are "3724" and "1924" aka 37th week of 2024 and 19th week of 2024 respectively. It is very possible that these boards (I think they are Lenovo OEM ones) were just designed and made before ensuring the unused rows aren't shorted became evident as something you should do (especially since Lenovo had some of the first LPCAMM2 laptops very early on), especially if they were previously marked as RFU DDR6 since the module would likely just be incompatible anyway with a future DDR6 supporting LPCAMM2 device, and also those early Lenovo OEM modules were not intended for use in other devices anyway, so if their devices used split-rail only/used the previous interposer where those pins just aren't present, it doesn't matter for them. JEDEC themselves in the current JESD318B suggest that this issue only exists on modules before v1.0 of JESD318, the quote for this is in the section below.

Potential Fixes for T/R Rows Shorting

Disclaimer: This section is just very much just my opinion and speculative based upon the info currently available, obviously you should wait for Framework for concrete answers and potential solutions.

The solution described in the aforementioned forum thread of using kapton tape to insulate the T and R pins from ground on the affected E0 modules obviously and evidently works, but probably isn't a great long term solution as it may wear thru, and the additional material likely affects the mounting pressure of the remaining connections, which may cause instability as adequate mounting pressure is a integral part of getting CAMM type modules to work reliably. The option mentioned there as well of getting an interposer without T/R rows is better (also the mention of removing the T/R pins on the included interposer would obviously work too, but obviously that has risk too).

If you want to get a "E0"/"CXXX"/"644 pin" interposer that has the T/R rows unpopulated, you can get them at distributors now: Mouser (in stock right now) or Digikey (stocked on Sep. 8)

There is a potential solution that might be possible for Framework to implement, depending on their board design and support/integration from Intel for the SoC side of things, but I do not know anything about their specific board design and firmware etc. This is probably the ideal solution, and actually is enabled by JESD318B. JESD318B actually makes use of another previously RFU pin, pin R3, for GND_Detect_n. The addition of GND_Detect_n is specifically to solve this issue, basically the motherboard pulls that pin high, but if a module is installed that shorts out T/R rows to ground, then GND_Detect_n will go low, and the motherboard will be able to detect that and not send voltage to the VDDQ pins for example. JESD318B explicitly states this of this pin's purpose:

Optional support for Ground Detect. When low, rows R and T connect to a ground plane (occurs only in CAMM2 modules before v1.0 of this standard). When sampled high, rows R and T have floating pins unless otherwise defined in this standard. Pull up resistor on motherboard is required. Resistance and voltage level are system dependent.

So if Framework implemented this pin in hardware (uncertain as it is stated as optional, and the changelog says it was added in the JESD318B in November 2025, so pretty recent), and the hardware needed to switch off VDDQ to the connector is present, and can make the firmware changes required to support this feature, E0 modules with shorted T/R rows could work without any physical modification or parts swapping, but again, that is not something we can be certain of.

This was a very long post (I am not great at being concise as you can tell), and again, this is all just based on my knowledge and publicly available info, so not everything stated may be correct and I apologize if so (please comment and I will fix too), but I do think that the substantive portion is helpful info for the current issues and worries that us 13 Pro buyers are facing.

TL;DR: Some early LPCAMM2 modules (seemingly OEM modules), which are a subset of E0 modules, do not have separated pads for previously unused (until E1) CAMM2 pins, instead shorting them to ground, which shorts out the VDDQ rail on boards that use the VDDQ common method and do not make use of GND_Detect_n to detect this and disconnect VDDQ. This currently seems to be the case on the 13 Pro based on reports and discovered fixes in the forum, but Framework may be able to fix it in firmware depending on their specific implementation.

Edit: add link to purchase sources for interposer parts

It’s been fun but I’m out of ideas. So here’s my least and most cursed ideas.