Recurring BIOS/Boot Failure, No Display; 12th gen firmware troubles; no error; post code 0x21

Framework Laptop 13 Linux
1

NOTE: I am making a service request too.

My 12th-gen intel Framework 13 seems to be bootlooping. This is not the first time this has happened. When I press the button, the button turns white (like it should), but the screen does not turn on.

It is completely off; from what I can tell, the LED backlight stays off.
Eventually, the laptop turns itself off, and then back on again.

This may have something to do with the Linux beta 3.08 firmware, which I unsuccessfully tried to flash. I think some of the USB-PD firmware was updated, but the rest failed. My attempts and errors are in the community thread.

This first happened a few weeks (I think? Time passes quickly) ago, and I followed the instructions to reset the mainboard on Framework’s support page, which worked.
Unfortunately, it happened again a few days ago, and due to a hurricane, I cannot access my screwdriver and perform the steps to reset the mainboard.

I am running Fedora Workstation 40 (upgraded from 38 to 39 to 40), using Grub 2 as my bootloader.
The main partition is LUKS encrypted, and I used to dual-booted windows, but eventually removed the partition and expanded my fedora partition to replace it.
While the partition table should be standard, I was a little suspicious that the EFI partition might’ve been to small or had other issues relating to the firmware update, and I had not set up the requisite partition for hibernation.

The only nonstandard part is my SSD drive (though I use a cablematters usb c charge cable and a 65W Anker brick). It is a 256 GB Samsung 960 Evo that I salvaged from another computer, but I updated the firmware and ensured its health was good. Unfortunately, as I detailed in a service request, the screw holding it to the motherboard is stripped, so I have been unable to swap it for a newer, higher capacity drive.

I bought my expansion cards when I bought the laptop. I do not recall if any of them are second-gen, but if I recall, the HDMI is not the newest available, as I wanted to replace it after upgrading the firmware.

The only other issue I have had (that I recall), and the main reason I wanted to update the BIOS, is poor charging detection on Fedora and Windows. While charging, both would occasionally think the charger had been unplugged, even when it hadn’t, and windows would go into battery saver. It would also seem to potentially discharge once fully charged and still plugged in, going from 100 to 99 and even lower, though I don’t think this correlated with its power consumption. From what I could see on the community forums, it seems this was caused by firmware bugs. It’s worth noting that the firmware updates that did potentially go through, for the USB-PD, did not seem to affect the behavior.

I recorded the following LED indicator sequence (video at bottom):

Orange (before turning on)
press power button, turns on, indicator LED stays orange
Green
Orange
Off
1 White Flash
power button and diagnostic LED off
8 Green Flash
Hold green (9 total? power back on)
3 Green flash
1 Orange flash
2 Green flash
1 Blue flash
4 Green flash
1 Blue flash
Orange
power button off, LED stays orange
power button on, LED stays orange
power button off, LED stays orange
power button on, LED blinks off, returns to orange
Repeat last two, except LED does not blink off

Interpretation of results (relying on this page):

No diagnoses (12 green flashes)

Post code: 00100001

In hex, this is 21, and according to the Insyde BIOS instructions, it corresponds to #define BDS_START_ISA_BUS 0x21 // ISA BUS driver initial

I do not know for certain that the endless repeating keeps the same indicator light pattern as shown here, but the power on and off continues.

During this sequence, I had in four expansion cards:
usb a (bottom left)
usb c (top left)
usb c (top right, plugged into outlet)
HDMI (bottom right)

However, when I removed the cards, or unplugged the power, the same issue occurred (though I did not check the indicator lights as closely)
In all cases, it turns on, the screen stays off, it turns itself back off, and then it repeats forever.
Holding down the power button can stop the loop, turning it off fully. I managed to discharge the battery by leaving it to run without being plugged in, and it repeated the loop until it ran out of charge. I do hear the fans when the power light is on, but potentially only after a few loops (presumably because the CPU heats up).

It has been several days since this started again, and I have been unable to reset the motherboard. Even if/when I can, I can’t afford to have this continue, so I want to figure out what’s wrong and if anyone else has the issue, and I am contacting customer service to see if I need to send it in to be fixed.

Video of LED sequence (though the fan spins up, the background noise is mostly not the fan): Boot Loop - Google Drive

EDIT: I do not know what triggered it. I think it was plugged in and sleeping or shut down overnight the second time, and I do not recall the trigger the first time, though it occurred the day I was trying to perform the bios/firmware update.

EDIT 2: I may have gotten the code wrong. This seems more likely:

1 Like
2

Not that this helps any, but I think you have the post code backwards, I believe that it is 10000100, or 0x84 which translates to

#define PEI_ENTER_RECOVERY_MODE               0x84        // Recovery device initial

Your best bet likely will be to do a mainboard reset once you have the screwdriver, then to get the bios upgraded successfully. Best of luck.

1 Like
3

Thank you. That does seem like a more likely error. Any idea as to why it recurred after I first reset the mainboard? That is the more worrying part to me.

4

This is just a guess but I would suspect the failed BIOS update may have things in an odd state.

1 Like
5

0x84 PEI_ENTER_RECOVERY_MODE

I don’t think FW have documented how to carry out “recovery mode”. I would contact them mentioning post code 0x84. If you have already contacted them mentioning post code 0x21, it would be worth correcting it to 0x84
When I did a BIOS upgrade on my FW16, it took a long time. Maybe 15-30 minutes. Enough for me to walk away from my desk as it was still spinning, so I don’t know exactly how long it took.

2 Likes
6

Thank you. The Framework Laptop 13 12th gen has some more specific firmware/bios update issues that Framework is aware of. They have been unable to get a proper linux installer out of beta. I put my info in the relevant thread.

1 Like
7

I have more or less precisely the same issue, except with one small difference—I have been unable to get a POST code out, because the machine tries to restart about halfway through the status LED’s blinking. I only get 3 or 4 bits of the POST code before the LED stops blinking as the system tries to restart.

8

Do you use tlp? I have a suspicion that only deep sleep causes this, as when I had my laptop docked and on AC power for days, it never occurred. I initially figured I must just have locked or shut it down, but now I am less sure. I’d test for myself, but I can’t afford to have it go down today or in the immediate future.

If you want to try, lmk how it goes.

image
image1690Ă—271 39.6 KB

9

I had the same suspicion, and have since switched to s2idle by default instead of deep_sleep (I had set it to deep_sleep manually, not via tlp). However like you I am too nervous to test whether this actually fixed it because I don’t want to have to go through the whole process of resetting things if it does not. (I guess it’s reasonably likely that I will accidentally put my laptop to sleep sometime soon and that will be a test of whether this fixed it, haha).

10

OK, it finally happened. I wasn’t paying attention to my battery life, left my computer on, and it went to sleep automatically—and then was stuck in the same boot loop. As before, nothing I tried could get it out, until I physically opened up the machine, took out the coin cell battery and disconnected the main battery to reset the mainboard state. :frowning: so it seems s2idle did not fix it.

11

FYI I just also submitted a support request about this issue.

12

One small update (I put it in the other thread too)—when running a live USB of Ubuntu 24.04, I was able to resume from suspend twice, but on the third time it got stuck asleep and wouldn’t resume. However I was able to hard power off and then reboot, and did not get stuck in the same boot loop.

1 Like
13

I think the suspend mode switches after losing 5% of power

14

Just wanted to note that suspend seems to be working for me now that I managed to get the BIOS upgraded, by first updating to 3.06 and then to 3.08. Details here. Cheers!